perm filename WORKS.MSG[UP,DOC]7 blob
sn#623886 filedate 1981-11-18 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00195 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00018 00002 Subject: Welcome to APOLLO
C00022 00003 Subject: Themes for discussion
C00025 00004 Subject: Preliminary results from the personal workstations survey
C00032 00005 Subject: personal computer economics
C00034 00006 Subject: Re: Another Xerox workstation.
C00036 00007 Subject: SAM/Worm/820
C00038 00008 Subject: personal computer economics
C00042 00009 Subject: personal computer economics
C00044 00010 Subject: Subjective value of Personal Workstations
C00047 00011 Subject: Star/Mesa
C00049 00012 Subject: Star
C00052 00013 [Subj: Mesa language, PDP10, etc]
C00054 00014 Subject: Re: Speaking up Xerox!
C00056 00015 Subject: Workstations, and their posts.
C00060 00016 Subject: correction on dlw's message
C00063 00017 Subject: Acquiring personal computers
C00068 00018 Subject: Arpanet usage
C00071 00019 Subject: Stars in the sky
C00075 00020 Subject: Productivity gains without using workstations
C00078 00021 Subject: Star Info
C00080 00022 Subject: Re: Apollo Network
C00086 00023 Subject: Quick overview/summary: The Apollo-I (Domain) computer.
C00089 00024 Subject: Re: Star Info
C00092 00025 Subject: Re: Star Info/Smalltalk
C00094 00026 Subject: Re: Smalltalk
C00096 00027 Subject: Chromatics
C00102 00028 Subject: Burroughs OFIS products
C00106 00029 Subject: Re: Works: Re RIvanciw: OA Architecture
C00110 00030 Subject: Apollo files and network
C00112 00031 Subject: Comment on note on Apollo Network
C00114 00032 Subject: Re: Quick overview/summary: The Apollo-I (Domain) computer.
C00116 00033 Subject: APOLLO net
C00119 00034 Subject: My CT system configuration and Chromatics
C00122 00035 Subject: Re: Personal Workstations -- who for?
C00128 00036 Subject: Interupting a workstation session
C00132 00037 Subject: Shades of Nicholas Negroponte
C00134 00038 Subject: Tools for personal workstations
C00137 00039 Subject: Languages for Distributed Workstations
C00143 00040 Subject: system architecture
C00146 00041 Subject: Mini/Micro Systems June 1981
C00147 00042 Subject: Re: Xerox Dolphin (alias 1100?)
C00153 00043 Subject: Personal Workstations
C00156 00044 Subject: The Economics of Workstations
C00163 00045 Subject: Interupting a workstation session
C00166 00046 Subject: Re: Tools for personal workstations
C00167 00047 Subject: frisbees and floppies...
C00169 00048 Subject: Addressing and File Accessing
C00172 00049 Subject: Re: el.POBox 19 Jun 81 7:36-EDT
C00173 00050 Subject: Multiple Levels Of State
C00177 00051 Subject: Re: Tools for personal workstations
C00181 00052 Subject: On productive text editors, suggested reading includes
C00182 00053 Subject: ALANTHUS System 1000 workstation
C00184 00054 Subject: Re: Xerox Dolphin (alias 1100?)
C00186 00055 Subject: Xerox 1100 (Dolphin)
C00188 00056 Subject: ALANTHUS System 1000 workstation
C00190 00057 Subject: Clarifications about interrupting workstaions
C00193 00058 Subject: Re: Multiple Levels Of State
C00195 00059 Subject: Question to field: Bit Mapped displays
C00196 00060 Subject: Addressing and File Accessing
C00198 00061 Subject: Re: File accessing?
C00199 00062 Subject: Re: Addressing and File Accessing
C00203 00063 Subject: Errata on Barns message "Addressing and File Accessing"
C00207 00064 Subject: Storage Question Restated
C00212 00065 Subject: Re: Addressing and File Accessing
C00215 00066 Subject: Re: Question to field: Bit Mapped displays
C00219 00067 Subject: capability machines
C00221 00068 Subject: Re: Addressing and File Accessing
C00225 00069 Subject: Re: Addressing and File Accessing
C00229 00070 Subject: Xerox 820 Ethernet compatability
C00231 00071 Subject: EMACS -vs- UNIX
C00238 00072 Subject: CMU Workstation milestone
C00239 00073 Subject: Re: Ethernet capabilities of 820 and STAR
C00247 00074 Subject: Switching tasks and context
C00251 00075 Subject: Multiple Levels of State
C00254 00076 Subject: Spatial design for a workstation
C00265 00077 Subject: Ivanciw's ideas &c: comments
C00270 00078 Subject: Re: Tools for personal workstations
C00272 00079 Subject: Re: capability machines
C00274 00080 Subject: Re: Spatial design for a workstation
C00276 00081 Subject: Contexts as Icons
C00280 00082 Subject: Multiple Levels of State
C00282 00083 Subject: Re: Switching tasks and context
C00286 00084 Subject: not putting phone messages into electronic mail files
C00288 00085 Subject: Re: A Quibble or two
C00292 00086 Subject: Re: not putting phone messages into electronic mail files
C00295 00087 Subject: Re: not putting phone messages into electronic mail files
C00298 00088 Subject: speaking of touch panels...
C00299 00089 Subject: Re: Spatial design for a workstation
C00301 00090 Subject: Context Managers
C00305 00091 Subject: Re: Re: Tools for personal workstations
C00306 00092 Subject: Re: Contexts as Icons
C00308 00093 Subject: Unfinished tasks, intra-office mail, and system death
C00312 00094 Subject: Re: A Quibble or two
C00314 00095 Subject: Reliability
C00318 00096 Subject: Re: JWalker comments on working at home, on planes, etc.
C00322 00097 Subject: Working at home
C00326 00098 Subject: Office of Tomorrow, where is it?
C00329 00099 [Subj: Bravo/Hypertext]
C00331 00100 Subject: Workstation Reliability and Redundancy
C00337 00101 Subject: Automated desk
C00340 00102 Subject: Re: Context Managers
C00341 00103 Subject: Icons
C00343 00104 Subject: Re: Reliability
C00347 00105 Subject: Touchpanels
C00351 00106 Subject: Re: Touchpanels
C00365 00107 Subject: Picture vs. Window names
C00372 00108 [Subj: more on icons]
C00374 00109 Subject: Re: Unfinished tasks, intra-office mail, and system death
C00376 00110 Subject: Reliablity
C00378 00111 Subject: SUN Workstation
C00380 00112 Subject: Collected Responses on Touchpanels II
C00395 00113 Subject: Re: Picture vs. Window names
C00397 00114 Subject: pukcba ekortsyek
C00399 00115 Subject: Making paper go away
C00404 00116 Subject: Programming by example
C00412 00117 Subject: Re: Reliablity
C00414 00118 Subject: PIE reports from PARC
C00415 00119 Subject: Quickie poll
C00416 00120 Subject: Re: Making paper go away
C00419 00121 Subject: Re: Making paper go away
C00423 00122 Subject: Making paper go away
C00427 00123 Subject: Re: Office of Tomorrow, where is it?
C00431 00124 Subject: Icons and analogy
C00435 00125 Subject: Redefining the art
C00437 00126 Subject: Re: Re: A Quibble or two
C00441 00127 Subject: Re: Spatial design for a workstation
C00448 00128 Subject: Re: Spatial design for a workstation
C00452 00129 Subject: Collected responses on terminal input devices
C00464 00130 Subject: Bell Labs "writers workbench"
C00465 00131 Subject: writing aids
C00466 00132 Subject: Realtime proofreaders
C00469 00133 Subject: Configuration
C00473 00134 Subject: [don: EP]
C00476 00135 Subject: Alternatives to making paper go away
C00479 00136 Subject: Re: Making paper go away
C00483 00137 Subject: Scanning structured text
C00485 00138 Subject: Editing
C00489 00139 Subject: Writing English
C00492 00140 Subject: Ideal word-processor
C00496 00141 ["Automate the Business Office--How and When"]
C00499 00142 Subject: Talking Workstations, that elusive 'external device'.
C00501 00143 Subject: mice,balls,touch-plates,pens.
C00504 00144 Subject: Re: Configuration
C00509 00145 Subject: Collected Responses on Terminal Input Devices
C00522 00146 Subject: terminals versus comp centers
C00525 00147 Subject: Collected responses on terminal input devices
C00546 00148 Subject: WorkS problems
C00550 00149 Subject: Realtime proofreaders
C00554 00150 Subject: File Backup
C00559 00151 Subject: Collected responses on terminal input devices
C00571 00152 Subject: More on configuration
C00577 00153 Subject: WorkS Software.
C00580 00154 Subject: Collected responses on useable systems
C00587 00155 Subject: Sperry Univac workstation design group -- eyewitness testimony
C00593 00156 Subject: Sperry Univac workstation design group -- eyewitness testimony
C00599 00157 ∂26-Jul-81 2028 AVB Xerox announcement on Dolphin/1100
C00607 00158 Subject: "mundane" systems
C00612 00159 Subject: re: REM' s remarks on Global configurations
C00617 00160 Subject: apollo s/w release 2.0
C00621 00161 Subject: Mouse Guts
C00627 00162 Subject: Big AND Small
C00635 00163 Subject: Keystroke Monitoring
C00638 00164 Subject: WorkS Digest V1 #1
C00649 00165 Subject: WorkS Digest V1 #3
C00660 00166 Subject: WorkS Digest V1 #4
C00663 00167 Subject: WorkS Digest V1 #5
C00681 00168 Subject: WorkS Digest V1 #6
C00690 00169 Subject: WorkS Digest V1 #7
C00697 00170 Subject: WorkS Digest V1 #8
C00704 00171 Subject: Announcements - ANSI Standards Comm. & NCC82 Call for Papers
C00710 00172 Subject: WorkS Digest V1 #9
C00713 00173 Subject: WorkS Digest V1 #10
C00723 00174 Subject: WorkS Digest V1 #11
C00731 00175 Subject: WorkS Digest V1 #13
C00740 00176 Subject: WorkS Digest V1 #13
C00746 00177 Subject: WorkS Digest V1 #14
C00749 00178 Subject: WorkS Digest V1 #16
C00755 00179 Subject: WorkS Digest V1 #17
C00762 00180 Subject: WorkS Digest V1 #18
C00764 00181 Subject: WorkS Digest V1 #19
C00769 00182 Subject: WORKS Digest V1 #20
C00784 00183 Subject: WORKS Digest V1 #21
C00790 00184 Subject: WORKS Digest V1 #23
C00798 00185 Subject: WORKS Digest V1 #24
C00810 00186 Subject: WORKS Digest V1 #25
C00814 00187 Subject: WorkS Digest V1 #26
C00821 00188 Subject: WORKS Digest V1 #27
C00831 00189 Subject: WORKS Digest V1 #28
C00862 00190 Subject: WorkS Digest V1 #29
C00878 00191 Subject: WorkS Digest V1 #30
C00882 00192 Subject: WorkS Digest V1 #31
C00891 00193 Subject: WorkS Digest V1 #32
C00902 00194 Subject: Works Digest V1 #33
C00911 00195 Subject: WorkS Digest V1 #34
C00923 ENDMK
C⊗;
Subject: Welcome to APOLLO
∂05-Jun-81 2215 DUFFEY at MIT-AI (Roger D. Duffey, II) Welcome to APOLLO
Date: 6 JUN 1981 0115-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: New APOLLO Subscribers
Hello,
Welcome to the APOLLO mailing list. APOLLO discusses personal
work station computers, like the APOLLO work station computer,
BBN's Jericho, the Three Rivers Corporation PERC, or the newly
announced Xerox STAR. APOLLO provides a way for interested
members of the ARPAnet community to discuss what is wrong with
these machines, compare notes on work in progress, and share
useful insights about these kinds of systems. The list is
managed by Hank Dreifus <Dreifus at WHARTON>.
APOLLO is currently discussing initial reactions to the Xerox
Star Workstation. Sandor Schoichet <SROSS at MIT-XX> has been
conducting an informal survey about the Star. The current
results are available in the file DUFFEY;APOLLO STARMS on MIT-AI
and the file <SROSS>STAR.MSS on MIT-XX. Please note that you do
not need to login to FTP the file from MIT-AI. People who cannot
obtain copies of the file themselves may request a copy of the
file by sending mail to APOLLO-REQUEST@AI.
Hank Dreifus <Dreifus at WHARTON> is conducting an initial
survey about the personal workstations people on this list
are using and/or developing. He would like to send him a
brief message describing the OA machine you use and why
(or why not). He will collect the responses and distribute
a final summary to the list.
A complete record of the APOLLO discussions will be maintained
in the file AI:DUFFEY;APOLLO ARCHIV. The archive is small now
because APOLLO is only a few days old. However, this will
change rapidly.
Comments in the ongoing discussions should be addressed to
APOLLO@MIT-AI. Administrative requests (eg. a message asking
to add someone to the mailing list) or questions about the
goals of this list should be addressed to APOLLO-REQUEST@MIT-AI.
Lastly, welcome to APOLLO. I trust you will enjoy being part of
these discussions.
Cheers,
Roger
Subject: Themes for discussion
∂11-Jun-81 0714 DREIFU at WHARTON-10 (Henry Dreifus) Themes for discussion
Date: 11 Jun 1981 (Thursday) 0915-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: APOLLO at MIT-AI
Some of the topics I would like to see discussed by this discussion
list are:
o Definition of a personal workstation.
o The IDEAL personal workstation.
o Technical review of all participating machines
where some accurate knowledge of the machine
can be presented.
o The introduction of personal workstations into large
business. The question of operational logistics,
transferring an application to a small machine.
o Is the right answer to make the small workstation
look like a very slow version of a large mainframe?
o Example applications.
o Trade offs in networking the workstations. Performance
weighed against cost and overhead.
o Some of the plans for introducing workstations in
operational areas.
o End user(s) of workstations, the application skewed
machines.
o User interfaces, factors.
------------------------------
There are but a few ideas. However one caveat. Facts are better
than Flames. Please no flaming, that is the one thing this list
is better off without.
Henry Dreifus
DREIFUS@WHARTON-10
-----
Subject: Preliminary results from the personal workstations survey
∂11-Jun-81 0735 DREIFU at WHARTON-10 (Henry Dreifus) Preliminary results from the personal workstations survey
Date: 11 Jun 1981 (Thursday) 0920-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: APOLLO at MIT-AI
Below is a condensed version of the various systems that people
have made an attempt to respond to. The interesting point(s)
that I have noticed are:
o Everyone's view of Personal Workstations is different.
o The machine(s) selected are wide ranged and apparently
well suited for each application chosen.
o There is no wrong Personal Workstation machine.
o The technology of Personal Workstations is not well
established as of yet.
o There is a demonstrated need for this technology,
it appears to be one year away from general use.
o Most have:
Large address space (or VM).
Networking capabilities.
Very good display hardware.
Large local storage capacity.
Micro-processor based.
Contain an external locator type input device.
o Most are missing:
Software tools to round out system.
Market recognition.
Gateway access, no gateway specifications.
Too many parts, development schedules are
full, revision schedules are bare.
Consistency. This is a result of different
definitions of what a personal workstation
is supposed to be.
------------------------------
Below is a summary of the survey responses. Eventually, each
machine will be examined in greater detail. The intention is
to educate ourselves about personal workstations. They sound
neat, but what they are under the surface is still a hot topic.
Machine Reason/Use Comments
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Perq Spice Project 15
Spice means: Scientific Personal Integrated Computing Environment.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Jericho BBN - Lisp machines 30
need large address
space and powerful
LISP processing.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
CTI For Alanthus. 16 workstations per
cluster capability.
(no numbers)
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
DEC-20/Ts computer Large Scale OA proj. 20
Interesting for discussion purposes.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Apollo Test/soft devt. 2 - max curr config.
existing in field
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Xerox Xerox Corp devt. 50-60
MIT, and others:
experimentation.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Nu's MIT Workstation 15-25
prototype
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Wang WPS-25 Experiment 1-4
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Extending the survey:
Each technical group that has a machine; eg Xerox PARC,
please designate one person to introduce their machine(s)
with references in the literature. For each agency or
sponsored group, list the application and the reasons and
any other relevant information about their specific problem,
eg: general Office Management, or some application. This
should provide a good beginning in opening the discussions.
Henry Dreifus
DREIFUS@WHARTON-10
-----
Subject: personal computer economics
∂11-Jun-81 0759 Hank Walker at CMU-10A (C410DW60) personal computer economics
Date: 11 June 1981 1025-EDT (Thursday)
From: Hank Walker at CMU-10A (C410DW60)
To: apollo at MIT-AI
Most of the comments on the Xerox Star that have appearred in the paper say
something like "very nice...for half the price". VERY few companies have
computer capitalization that exceeds $10,000 per person. That's roughly
what it is at DEC (internal transfer cost), and the average outside company
would have to spend a lot more to reach the same level, which I consider
just adequate (terminal at home, one at work, access to several group
machines). The comments that I have heard from people in marketing are
that they don't think that large numbers of the Star will be sold to peons,
but rather to management types, who can use it as a status symbol.
So one requirement of a personal workstation that you are going to give
to everybody, including the secretaries, is a price of less than $10,000
including overhead from network, printer, file servers, etc. Also including
software.
Subject: Re: Another Xerox workstation.
∂11-Jun-81 1213 Charles B. Weinstock <Weinstock at SRI-KL> Re: Another Xerox workstation.
Date: 11 Jun 1981 1123-PDT
From: Charles B. Weinstock <Weinstock at SRI-KL>
To: TAW at SU-AI
cc: apollo at MIT-AI
In-Reply-To: Your message of 11-Jun-81 0918-PDT
The 820 (or Worm) is a 64k Z80 based machine that (at 3k) has a
keyboard, display, two mini-floppies, and can run either CP/M or
a Xerox hacked over Wordstar (this from the local representative).
The only current Ethernet capability is through a RS232 interface
(which means that an Apple or a Osborne has the same capability).
Xerox will have some sort of a real Ethernet available eventually.
According the the San Jose News of last night, the 820 has no
graphics capability. The main thing this @i[appears] to have going
for it is the Xerox name--many companies would rather deal with a
Xerox or an IBM than an Apple or a Radio Shack or a ...
The above is based on information gleaned from talking to various Xerox
people and is no doubt incomplete. I imagine there are Xeroxers on
this mailing list. Perhaps they can fill us in more.
-------
Subject: SAM/Worm/820
∂11-Jun-81 1241 Tom Wadlow <TAW at SU-AI> SAM/Worm/820
Date: 11 Jun 1981 1131-PDT
From: Tom Wadlow <TAW at SU-AI>
To: apollo at MIT-AI
Hopefully, Xerox will provide the software for the 820 to speak with Star
systems. That is where the 820 could have the advantage over the Apple
or Osbourne machines. I think that a lot of people who would like to
go into office automation are cringing at the price of the Star (when they
think of all the people that they would want on their office network).
If the 820 provides a thoughtfully designed subset of Star capabilities
(and I don't know whether it will or not) at a fraction of the price
it could be a wonderful bootstrapping mechanism for getting Ethernet
based systems into the offices. And you can always unplug the 820
and plug in a Star at a later date (perhaps allowing the employees
to take them home for telecommuting purposes).
Subject: personal computer economics
∂11-Jun-81 2242 Steven T. Kirsch <SK at MIT-MC> personal computer economics
Date: 12 June 1981 01:34-EDT
From: Steven T. Kirsch <SK at MIT-MC>
To: Hank Walker at CMU-10A
cc: apollo at MIT-AI
I think your argument is a little incomplete.
Suppose I make you the following deal: if you give me $10,000 today, I
will give you at least $5,000 every year for the next 5 years. I
think you will accept my deal, right?
Ok, now let's look at Star and suppose I can prove to you that it
makes me 10% more effective (this is hard to prove) or that it saves
me 10% of my time. My time actually costs the company $60,000 a year.
And I am but a lowly engineer making under $30K/year. So if the
if I do my work 10% faster, the company in some way, "saves"
$6,000/yr. (the savings could be in hiring less engineers or by
getting more work done per unit time or by getting the job done more
effectively).
In fact, the Booz-Allen study on the potential of office
automation (a very thorough case study of over 40 companies) concluded
the AVERAGE ROI on OA equipment was 86% annually and could be over
200% in some companies.
I think it is foolish to measure a system on cost. You measure on
price/performance or ROI. If Xerox can prove a high ROI, they will win.
I must work for one of those "VERY few" companies who spend over
$10,000 on computer equipment for engineers. It costs us $60,000 to
provide a computer port into our Data General Eclipse.
∂12-Jun-81 0051 Dave Dyer <DDYER at USC-ISIB> personal computer economics
Date: 12 Jun 1981 0043-PDT
From: Dave Dyer <DDYER at USC-ISIB>
Subject: personal computer economics
To: apollo at MIT-AI
While your fundamental argument is correct, you neglected two
important points.
First, the $10K (or whatever) is not free. At today's rates,
$10K capital investment costs the company 20% interest, either directly
because they had to borrow it, or indirectly, because they don't have
it to invest elsewhere. So your increase in productivity would have to
be at least 20% to break even.
Second, as someone else has pointed out, no one knows how to quantify
the increase (if any) in productivity from something like a star, especially
vis a vis similar software running on less flashy hardware. This makes
it impossible to "prove" any increase in productivity.
-------
Subject: personal computer economics
∂12-Jun-81 0051 Dave Dyer <DDYER at USC-ISIB> personal computer economics
Date: 12 Jun 1981 0043-PDT
From: Dave Dyer <DDYER at USC-ISIB>
To: apollo at MIT-AI
While your fundamental argument is correct, you neglected two
important points.
First, the $10K (or whatever) is not free. At today's rates,
$10K capital investment costs the company 20% interest, either directly
because they had to borrow it, or indirectly, because they don't have
it to invest elsewhere. So your increase in productivity would have to
be at least 20% to break even.
Second, as someone else has pointed out, no one knows how to quantify
the increase (if any) in productivity from something like a star, especially
vis a vis similar software running on less flashy hardware. This makes
it impossible to "prove" any increase in productivity.
-------
Subject: Subjective value of Personal Workstations
∂12-Jun-81 0447 Brian P. Lloyd <LLOYD at MIT-AI> Subjective value of Personal Workstations
Date: 12 June 1981 07:39-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: APOLLO at MIT-AI
Regardless of the arguments for and against the economic value of the
Personal Workstation (PW), the numbers are beginning to tell. I work
for Alanthus Data Communications and we market the Convergent
Technologies system to end users. Our marketing strategy is to point
out how the system provides OA, communications, and user
programmability in one box.
The response is overwhelming! The average configuration seems to be
going out at about $20,000 including software. Granted, at this point
in time people are buying development systems, but the availablity of
OA software (WP, mail, etc.) has been a driving point in almost every
sale.
Obviously people believe in the PW concept and the market is still
growing. Since people rarely exhibit rational behavior (except in a
negative [fiscal] sense), I don't expect rational decisions either way
on the subject. We all realize that OA and PWs are coming and noone
is going to stop it.
Since we all tend to be in areas of development for OA products, let
us now discuss what the needs of the user really are. Perhaps we can
decide what Office Automation and Personal Workstation really means.
Brian
Subject: Star/Mesa
∂12-Jun-81 0841 LYNCH at USC-ISIB Star/Mesa
Date: 12 Jun 1981 0819-PDT
From: LYNCH at USC-ISIB
To: Apollo at MIT-AI
The Star is almost useless to any of us who are doing computer
science R&D unless we can program it as we see fit. The applications
that Xerox has seen fit to release at this time are indeed quite nice
but do not justify the cost ($20K with software if you buy 50 or more
of them in a year's time -- they give a nice discount for volume
buys (about 25% off)). We asked Xerox to include Mesa.
They said OK. They have not yet quoted a price to us however.
We also asked for the microcode. Thye said Not at this time.
The Mesa release was contigent upon us buying a lot of them
(like 50-100). They are still confused about where their marketplace
is. If commerical orders do not flow in rapidly in the next
few months then they might be much more interested in
turning it into a "programmer's workstation" that would suit us.
WEe have also asked them to include much more memory on the Star.
They admit it can be done but that they are trying to build even
smaller confiturations of it (it currently comes with 384 MB).
Dan
-------
Subject: Star
∂12-Jun-81 0940 Tom Wadlow <TAW at SU-AI> Star
Date: 12 Jun 1981 0917-PDT
From: Tom Wadlow <TAW at SU-AI>
To: apollo at MIT-AI
As I understand it, the Star comes with a somewhat low-power programming
language called CUSP. This is the only programming facility available to
the user. Rumor has it (and it would not surprise me) that there is an
extensive Mesa development system that could be run on the Star, but is
destined to never leave the hallowed halls of Xerox. (If I am wrong
on any of this I will cheerfully accept correct information from our
friends at Xerox who are reading this)
Apparently the reasoning behind this involves consistancy in system
software. If you don't give the users (who aren't supposed to be
programmers to begin with) access to the system programming language,
and armor-plate the language that you do give them, they can't
do themselves or the system any harm. Also, if you want a new
system application, you must ask Xerox to make it for you. Thus
it will be written properly (I am not being sarcastic here. There
is a lot to be said for this approach when your target market is
composed of non-programmers). Xerox doesn't want to find themselves
in the position of supporting outside software, because outsiders
don't have the information and the methodology to write that
software in a consistant manner with the rest of the Star system.
[Subj: Mesa language, PDP10, etc]
∂12-Jun-81 2016 Ian H. Merritt <MERRITT at USC-ISIB>
Date: 12 Jun 1981 1529-PDT
From: Ian H. Merritt <MERRITT at USC-ISIB>
To: CSVAX.fateman at BERKELEY
cc: apollo at MIT-AI, MERRITT at USC-ISIB
In-Reply-To: Your message of 12-Jun-81 0736-PDT
The major problem we have encountered at ISI is not the hardware costs, but
unwillingness of Xerox to supply us with the facilities to write our own
system software. The eventual availability of the Mesa language has been
discussed, but we need all the system software in order to configure the
system to be useful for our applications.
Another consideration is the internet protocols which are (as I am led to
believe) currently not supported.
The idea of using PDP-10s as 'glorified file servers' has been discussed
and seems to be the best way to proceed, since there is currently no part
of the product line which will afford us the massive storage and archival
system we require.
<>IHM<>
-------
Subject: Re: Speaking up Xerox!
∂12-Jun-81 2037 Hamilton.ES at PARC-MAXC Re: Speaking up Xerox!
Date: 12-Jun-81 16:32:59 PDT (Friday)
From: Hamilton.ES at PARC-MAXC
In-reply-to: GEOFF's message of 12 Jun 1981 1421-PDT, <[SRI-CSL]12-Jun-81 14:21:10.GEOFF>
To: Geoff at SRI-CSL
cc: Apollo@AI, Hamilton.ES
We (Xeroids) have been informed that "according to Xerox management,
Xerox policy is to send NO information on Xerox products over the
Arpanet. Thus, APOLLO should be considered to be one-way (inward
only) with regard to Xerox products."
I'm just a low man on the totem pole, so I speak only for myself,
but I suspect that there are two concerns here. One is that we
don't want to do anything that could be construed as "selling"
(even if only as a passive response to people's technical questions)
over the net. The other is that we insiders tend to lose track
of what's officially announced and what isn't, and what's part of
our product as opposed to our development environment.
I certainly encourage other Arpanet sites to share their perceptions
and expectations of Star. Doubtless such reactions will be one of
many valuable sources of input to determine the product's future.
--Bruce
Subject: Workstations, and their posts.
∂12-Jun-81 2244 DREIFU at WHARTON-10 (Henry Dreifus) Workstations, and their posts.
Date: 12 Jun 1981 (Friday) 2233-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: apollo at MIT-AI
User interface, how important?
The Apollo has nothing right at the moment, as compared to the Star, in
which almost the total software engineering effort has been skewed.
Building a powerful user interface is ''nice'', but what is left
with respect to processor cycles is not so ''nice''. The questions of
priorities for any given application is not clear.
Example:
o Personal workstations are purchased because;
(a) Small application program needs to be run off mainframe
(b) Office - management systems need more sophistication
(c) Need for specialized computing has grown
(d) Corporations can no longer shell out vast sums of
money on computing, when distributing is available.
o What personalities should personal workstations have?
In answering this, there are basically 2, a truely split
personality:
Consider:
System FOO runs on giant IBM-303x and can really be run on
lots of distributed perscoms [from G. Steckel].
Systems people would like to see a very interactive and
totally controllable system, perhaps right down to the
micro-code. The full power, memory management right through
to the disk-I/O routines. Engineering a product right is
as equivalent to engineering it well.
Management would want to see just the pretty pictures, the
finished product, none of the rough edges, that the software
engineers love to play with. All they want is a black box with
none of the 'hassles' of low level code.
A split personality indeed.
Most systems are geared towards the management. The fact that
few provisions have been made for the systems types is indeed a
potential tragedy. Much of the insulation is hindering a good job for
the programmer. Remember these things are nothing more powerful than
your Apple computer, doing a major application in-efficiently will hurt
the perscoms in the long run.
Opinions?
/Hank
Subject: correction on dlw's message
∂13-Jun-81 1122 CSVAX.halbert at Berkeley correction on dlw's message
Date: 13 Jun 1981 10:32:20-PDT
From: CSVAX.halbert at Berkeley
To: apollo@mit-ai
The Xerox Star does have virtual memory; it does page.
--Dan
∂13-Jun-81 1151 LYNCH at USC-ISIB Re: correction on dlw's message
Date: 13 Jun 1981 1144-PDT
From: LYNCH at USC-ISIB
Subject: Re: correction on dlw's message
To: CSVAX.halbert at BERKELEY, apollo at MIT-AI
cc: LYNCH
In response to the message sent 13 Jun 1981 10:32:20-PDT from CSVAX.halbert@Berkeley
But I have heard the paging on the Star is a terrible crock:
it does it by double lookup on every memory reference way down
in the microcode. At this time it has no hardware to assist
paging (like associative memory for the TLAs) or even a
kludge like KL-10s have. The (mis)feature makes it tough
to imaging the STar as a LISP machine host.
Dan
-------
∂13-Jun-81 1236 mike at RAND-UNIX MESA on Star
Date: Saturday, 13 Jun 1981 12:18-PDT
To: apollo at MIT-AI
Subject: MESA on Star
From: mike at RAND-UNIX
I have heard a rumor, from a source I trust, that MESA will be
available to those who buy 50 or more Star's. I do not know if there
will be a heavy price, nor do I know if this is a special deal to non-
profit or educational institutions or special in some other way.
There is someone on this list -- you know who you are -- who can
confirm or deny this rumor authoritatively if he chooses to.
In any case, I believe that MESA is a good systems programming
language, but you can certainly kiss portability goodbye!
Subject: Acquiring personal computers
∂13-Jun-81 1415 Sam.Harbison at CMU-10A Acquiring personal computers
Date: 13 June 1981 1534-EDT (Saturday)
From: Sam.Harbison at CMU-10A
To: apollo at mit-mc
Message-Id: <13Jun81 153417 SH01@CMU-10A>
There's been a lot of discussion about the pro's and con's of various personal
computers/personal workstations. Let me give a brief summary of some decisions
taken at CMU.
About two years ago, the CS department decided that our long-term computing
needs would be best met by a network of personal computers in offices, and
plans were made to embark on a research project (Spice) that would give us by
1985 the kind of software necessary for such an facility (including Lisp and
Ada programming environments, document production environments, and multi-media
communication). We thought that it would be 1985 before personal computers
appeared with the right power and cost. Because we did not want to do any
hardware design, we began to canvas manufacturers to see 1) what was available
now to start with, and 2) what might be available in 1985.
The machines close enough to what we wanted to act as a prototype were Perqs,
Apollos, Lisp Machines, Nu Machines, and Xerox D-machines (Dolphin, Dorado, and
the Star computer). Our principal criteria were that the machine had to have
all the basic features of a 'real' machine (display, net, etc.) and be flexible
enough to allow us to develop software for the 1985 machines now. Furthermore,
it was important that we be able to distribute our software to other people.
To make a long story short, Apollos and Nus did not have the writable
microstore that we considered critical, and their microprocessors did not seem
to be able to support the kind of multiprogramming we wanted. Lisp Machines
were too expensive and production (then) uncertain. Xerox and their machines
were philosophically close to us, but the Dolphin/Dorado were not commercial
products, and Xerox would not commit to releasing Mesa, meaning that we might
find it difficult to distribute a system built in Mesa. We finally chose to
begin with Perqs, which on paper are at least equal in performance to any of
the others except the Dorado and Lisp Machine. (And which can be
microprogrammed to be very much like the machine we really want, except for
performance.) The Star's advantage quoted by others is, I think, due to
software refinement. We now have fifteen Perqs at CMU, and work on Spice is
proceeding rapidly. We continue to be on the lookout for new hardware that can
be used in the Spice system in years to come.
Our criteria for machines may not be the same as other people's; we are heavily
committed to "high-end" personal computers, and the software available was
relatively unimportant to us. However, if Mesa and its compilers were freely
available the Xerox machines would have been very attractive.
Subject: Arpanet usage
∂17-Jun-81 0551 Liddle at PARC-MAXC Arpanet usage
Date: 16 Jun 1981 17:45 PDT
From: Liddle at PARC-MAXC
To: AllDLOS↑.DLOS, AllEOS↑.EOS, AllES↑.ES, AllHENR↑.HENR, AllPA↑.PA,
AllWBST↑.WBST, AllXRCC↑.XRCC
cc: Apollo at MIT-AI, Liddle
Many of you in Xerox are aware of a newly created Arpanet distribution list
named Apollo. It was established to promote discussion of personal workstation
computers. As you might expect, much of the recent discussion has involved the
Xerox 8010 Star information system. Because many of the messages ask for
information about this product and its associated development software, you may
feel tempted to reply to some of them.
It is ARPA policy that the Arpanet be used only for government supported
research and development. It is against Xerox policy to use the Arpanet to discuss
products. It is completely inappropriate to use the Arpanet in a way that may be
construed as selling or promoting a Xerox product (or future product). Xerox
employees use the Arpanet for ARPA related research purposes only, not for
answering questions or distributing information about our products.
Questions from potential customers about the Xerox 8010 and other OPD products
should be referred to Arnold Palmer, Field Sales Manager, Xerox Corporation,
1341 West Mockingbird Lane, Dallas, Texas 75247, phone (214) 689-6689.
David E. Liddle
Vice President
Office Products Division
Subject: Stars in the sky
∂19-Jun-81 0555 mo at LBL-UNIX (Mike O'Dell) Stars in the sky
Date: 17 Jun 1981 09:15:54-PDT
From: mo at LBL-UNIX (Mike O'Dell)
To: info-micro at mit-ai
Redistributed-To: WorkS at AI
Redistributed-By: GEOFF at SRI-CSL
Redistributed-Date: 17 Jun 1981
Last week we had a briefing on the Star, so I will relate what was said.
The processor is a D3 machine, and is claimed to run Mesa about
3 times faster than a D0 or a Dolphin. The D3 is a 32-bit, virtual
memory design. The Star only has about 200kb
of memory on it, expandable to about .5 megs, but there is every
reason to believe it can have a lot more than that on it. The
office automation software is all written in Mesa and the base of
the machine is Pilot, but you can't get to any of this. The is a lot
of discussion about making the Mesa environment available, but so
far there is a negative corporate attitude. If they would just
realize how neat that would be.... Anyway, the office software is
pretty classy, but their pricing is repressive. By the time you
license all the software (math editor, graphics, spelling corrector, etc),
which must be done for EACH machine, you add about $5K to the price.
The killer, however, is software maintenance for that machine will
be close to $500 per month!!!!! The pricing structure allows hardware
quantity levels to count the various servers (com, file, print, etc)
as well as Stars because they all use the same CPU box, but
quantity levels for software count only Stars. Software for the
other servers is priced the same way. The basic file server does NOT
come with the electronic mail facility. That handy option costs extra.
Rumors abound pertaining to the transport of Smalltalk and Interlisp
to the machine, but like with Mesa, Xerox doesn't see any demand for
user programmable machines. Moreover, if they can continually
squeeze money out of you for software, it is to their advantage
that no one else can build software for it. (Personal comment)
If any mere mortal (other than MIT, CMU, and Stanford) can
shake Mesa out of Xerox, let me know.
-Mike
Subject: Productivity gains without using workstations
∂24-Jun-81 0511 DPR at MIT-XX Productivity gains without using workstations
Date: Tuesday, 23 June 1981 10:02-EDT
From: DPR at MIT-XX
To: WORKS at MIT-MC
Kirsch has an extremely valid point. The fundamental question is what
leverage does computerization provide in doing a function. However, let's
not be miserly--even Xerox STAR's are incredibly cheap as an investment,
so the amount of leverage they must provide is small.
Personally, I think companies with cash to invest ought to invest it
in ecnomic sectors of maximum productivity gain--however, there are
immense barriers to this. Most companies restrict themselves to internal
reinvestment of their funds. Since our largest and least productive
companies have the higher percentages of funds to invest, and since they
are largely white-collar offices, there is a great move toward
office automation, even though productivity gains are slim in most
office applications.
The sterling exception to this observation about the utility of workstations
lies in tools of high leverage like VisiCalc--which make order of magnitude
changes in labor required to do a task. The Star seems to be able to do this
with the production of business graphics--but I am not sure that they
will be largely used in this domain, or if the graphics thus produced
would have been produced had there not been a Star.
Subject: Star Info
∂24-Jun-81 0533 UOFILLINOIS at WPAFB-AFWAL Star Info
Date: 23 Jun 1981 (Tuesday) 1419-EDT
From: UOFILLINOIS at WPAFB-AFWAL
To: works at MIT-AI
cc: gdh at MIT-AI
The STAR people came here to talk today.
Here's some facts/rumors that were new
to me:
o Mesa will probably be released for
the STAR either the 4th quarter of
this year or the 2nd quarter of next
year.
o Smalltalk "will NOT be released on the
STAR or anywhere else" -- a "small
outfit in Silicon Valley" (not PARC --
I'm not sure who they're talking about)
licensed it to HP, TI, and Apple. When
the STAR marketing people found out,
they "put a stop to it"
o A personal computer called the "inch-
worm" will apparently be announced
soon. It is about book-sized, has
a bitmapped display, and measures
about an inch thick (hence the name).
Could this be a first pass at the
Dynabook?
o They won't sell just one STAR until
next year
-geo
Subject: Re: Apollo Network
∂24-Jun-81 0554 mike at RAND-UNIX Re: Apollo Network
Date: Tuesday, 23 Jun 1981 10:39-PDT
To: Eric Benson <BENSON at UTAH-20>
Cc: WorkS at MIT-ML, DLW at MIT-AI
In-reply-to: Your message of 22 Jun 1981 1043-MDT.
From: mike at RAND-UNIX
You say that the 'apollo software is another story'.
Well, OK, what's the story?
When I was visiting Apollo, it was clear that the hardware was close
to working and that they had no idea just how hard the software they
were planning was going to be to write. Either they didnt know or
they were trying to tell me a story.
Specifically, they intended to write a truly network distributed file
system: with paging, swapping and file transfers all completely
independant of the local machine which might or might not have a disk
drive. When I asked them what file names would look like, to get an
idea of whether the file name would contain the name of the root file
system (location) or whether the location would be 'hidden' from the
user: they had no idea. They had never even thought of the question.
It is possible that there was someone in the building who knew
something about software, but I didnt have the opportunity to meet
them.
I was also not overwhelmed with their desire to build a non-standard
network. But their attitude seemed to be: this is what Prime is doing
and we are really from Prime so this is what we are doing.
Update ??
∂24-Jun-81 0606 Dave Crocker <dcrocker@udel> Apollo gatewaying
Date: 23 Jun 81 11:11:25-EDT (Tue)
From: Dave Crocker <dcrocker@udel>
To: Works at Mit-Ai
Subject: Apollo gatewaying
We had an Apollo presentation, given by Dave Nelson, one of
their Development VPs. He said that a gateway (to unspecified
other networks) was planned. Guess I would expect the initial
one to be to others of their (Domain) rings.
It was my impression that the basic network environment is
strictly message/packet oriented, without connections or other
efficiency mechanisms. Nelson pointedly stated (it was too
affirmative to class as an "admission") that they were not
oriented toward file transfers . Such things can and are done,
but the environment is not tuned to them.
Dave
∂24-Jun-81 0617 DREIFU at WHARTON-10 (Henry Dreifus) Quick overview/summary: The Apollo-I (Domain) computer.
Date: 23 Jun 1981 (Tuesday) 2308-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Quick overview/summary: The Apollo-I (Domain) computer.
To: WorkS at MIT-AI
The structure of the Apollo computer network:
--- --------- -- --- ------ -------- --------
Summary:
o ~~ 12 Mbit bandwidth
o standard Coaxial RG58 cable
o Ring structure, single band.
o Token passing [Cambridge Ring Network concept]
Fixed packet sizes [I believe 4K bytes] are constructed for
transmission from one "node" to another. A "node" consists of a
68000 and a winchester disk drive.
∂24-Jun-81 0627 Griss at UTAH-20 (Martin.Griss) More on DOMAIN
Date: 23 Jun 1981 0741-MDT
From: Griss at UTAH-20 (Martin.Griss)
Subject: More on DOMAIN
To: Works at MIT-ML
cc: griss at UTAH-20
Discussions we have had with Apollo indicate that they are aware of the
MultiBus Ethernet board, and certainly plan to use the MUltiBus crate for this
level of I/O support board (NOT MultiMaster usage); my guess is that one of the
university people with an Apollo is likely to try to do the Ethernet Interface
software, most likely after a C is working. Any comments from Brown U. ?
M
-------
Subject: Quick overview/summary: The Apollo-I (Domain) computer.
∂24-Jun-81 0617 DREIFU at WHARTON-10 (Henry Dreifus) Quick overview/summary: The Apollo-I (Domain) computer.
Date: 23 Jun 1981 (Tuesday) 2308-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: WorkS at MIT-AI
The structure of the Apollo computer network:
--- --------- -- --- ------ -------- --------
Summary:
o ~~ 12 Mbit bandwidth
o standard Coaxial RG58 cable
o Ring structure, single band.
o Token passing [Cambridge Ring Network concept]
Fixed packet sizes [I believe 4K bytes] are constructed for
transmission from one "node" to another. A "node" consists of a
68000 and a winchester disk drive.
∂24-Jun-81 0627 Griss at UTAH-20 (Martin.Griss) More on DOMAIN
Date: 23 Jun 1981 0741-MDT
From: Griss at UTAH-20 (Martin.Griss)
Subject: More on DOMAIN
To: Works at MIT-ML
cc: griss at UTAH-20
Discussions we have had with Apollo indicate that they are aware of the
MultiBus Ethernet board, and certainly plan to use the MUltiBus crate for this
level of I/O support board (NOT MultiMaster usage); my guess is that one of the
university people with an Apollo is likely to try to do the Ethernet Interface
software, most likely after a C is working. Any comments from Brown U. ?
M
-------
Subject: Re: Star Info
∂24-Jun-81 1838 Deutsch at PARC-MAXC Re: Star Info
Date: 24 Jun 1981 10:17 PDT
From: Deutsch at PARC-MAXC
In-reply-to: UOFILLINOIS' message of 23 Jun 1981 (Tuesday) 1419-EDT
To: UOFILLINOIS at WPAFB-AFWAL
cc: works at MIT-AI, gdh at MIT-AI
I would like to correct some erroneous information about Smalltalk and the Star.
o Smalltalk "will NOT be released on the
STAR or anywhere else" -- a "small
outfit in Silicon Valley" (not PARC --
I'm not sure who they're talking about)
licensed it to HP, TI, and Apple. When
the STAR marketing people found out,
they "put a stop to it"
The truth is that LRG, a group within PARC, has licensed Smalltalk-80 (the only
Xerox-authorized version of Smalltalk to be released) to a number of micro- and
mini-computer manufacturers. The release consists of detailed specifications for
the machine-dependent kernel, plus a mag tape containing the rest of the system
(windows, editor, compiler, file system, etc., etc.) Several of these manufacturers
have made excellent progress on implementing the system, to the point of having
windows appear on their displays. I can't comment on the specific list of
manufacturers, since we prefer to let them make their own announcements. The
Star marketing people have not exerted any pressure in either direction with
respect to this; the release/license process was properly cleared with our legal
department and all relevant product organizations within Xerox, and we are
currently working out ways to license the system to manufacturers (and
universities) beyond the original group. I can't comment on the availability of
Smalltalk for the Star, except to say that the Star hardware is definitely powerful
enough to support Smalltalk.
Subject: Re: Star Info/Smalltalk
∂24-Jun-81 1911 Ron Newman <Newman.es@Parc-Maxc> Re: Star Info/Smalltalk
Sender: Newman.ES at PARC-MAXC
Date: 24-Jun-81 9:48:22 PDT (Wednesday)
In-reply-to: UOFILLINOIS' message of 23 Jun 1981 (Tuesday) 1419-EDT
From: Ron Newman <Newman.es@Parc-Maxc>
To: UOFILLINOIS at WPAFB-AFWAL
cc: Newman.es, works at MIT-AI, gdh at MIT-AI
Who were "the STAR people" that came to talk to you?
Smalltalk IS being released by PARC this summer. There was a big presentation
on the subject at this year's NCC. Apple, DEC, HP and other companies are
doing research into implementing it on their machines. (In fact, one of the
primary Smalltalk implementors, Larry Tesler, is now at Apple and was one of
the speakers at NCC.) A huge article on the subject will appear in the
August issue of BYTE.
The deal is that PARC gives you an "image" file on a tape, whichcontains
all of Smalltalk ready to run. To run it, you have to implement an
interpreter on your machine for the 256 Smalltalk bytecodes. Just like you
can run Pascal, if you have a P-code interpreter.
(I don't think anyone at Xerox will beat up on me for this message; all of
it comes from strictly public sources.)
/Ron
Subject: Re: Smalltalk
∂24-Jun-81 1951 mike at RAND-UNIX Re: Smalltalk
Date: Wednesday, 24 Jun 1981 11:45-PDT
To: WorkS at MIT-AI
From: mike at RAND-UNIX
Forgetting for a moment about Xerox marketting, Xerox intends to
release a book on Smalltalk called Smalltalk 80. This version of
Smalltalk is intended to be easily portable. There was some
discussion within Xerox legal about whether the Smalltalk virtual
image would be released. But the book which describes the interpreter
plus the virtual image would result in a very easily portable
language.
One could then port it to the machine of your choice, including the
STAR, assuming that you could PROGRAM the STAR. When MESA gets
released you will be able to implement it in that: but a better place
is microcode. I haven't heard anything definitive about whether Xerox
intends to microcode the Dandelion (STAR workstation) for Smalltalk.
Xerox marketing wasn't trying to mislead, I'm sure. They have no
interest in marketing Smalltalk; just word processing.
Michael
Subject: Chromatics
∂24-Jun-81 2036 cfh at CCA-UNIX (Christopher Herot) Chromatics
Date: 24 Jun 1981 10:39:46-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: WorkS at mit-ai
I saw the Chromatics CGC 7900 "Color Graphics Computer" at
the National Computer Graphics Association show last week.
It's hardware is:
Motorola 68000
1024 x 768 x 8 bit color display w/24 bit lookup table
10Mb Winchester disk
Dual Floppies
Light Pen
Joy Stick
151 (I'm not kidding) Key Keyboard
Prices range from $25,000 to $50,000 depending on how much memory
and other options you buy. It doesn't have virtual memory like
the Apollo but can take quite a bit (at least a meg) of real memory.
They plan on supporting IDRIS, a UNIX clone, sometime soon.
Address:
Chromatics, Inc.
2558 Mountain Industrial Boulevard
Tucker, Georgia 30084
404-493-7000
∂24-Jun-81 2052 guyton at RAND-UNIX Re: Chromatics Personal Workstation
Date: Wednesday, 24 Jun 1981 16:13-PDT
To: PRSPOOL at RUTGERS
Cc: WorkS at MIT-AI
Subject: Re: Chromatics Personal Workstation
In-reply-to: Your message of 23 Jun 1981 1139-EDT.
From: guyton at RAND-UNIX
The Chromatic 7900 workstation has been announced for a while now and they
had one at the Chicago NCC. Their address/phone:
Chromatics
2558 Mountain Industrial Boulevard
Tucker, Georgia 30084
(404)493-7000
Here a few facts off their CGC 7900 literature:
16-Bit processor (MC68000)
19" color monitor
1024x768 viewable bitmap (in a 1024x1024 bitmap memory)
Up to 256 simultaneously displayed colors
Palette of over 16 million colors (i.e. 8-bit DAC for RGB)
10MB Fixed Winchester Disk (8.4 MB formatted)
Dual floppies
light pen, joystick
Maximum of 16-bitmap planes (no more than 8 displayed at once)
Maximum of 2MB of processor memory
Rand reviewed this machine last year and might have purchased one if it
hadn't been quite so new (at the time they had not delivered any, and we
needed a mature system). When I priced it, a useful system was running
around $60K.
Oh yes, they're planning on running the 68000 unix look-alike.
Jim
∂24-Jun-81 2109 Robert A. Morris <RAM at MIT-MC> Chromatics Personal Workstation
Date: 24 June 1981 18:57-EDT
From: Robert A. Morris <RAM at MIT-MC>
Subject: Chromatics Personal Workstation
To: PRSPOOL at RUTGERS
cc: WorkS at MIT-AI
According to a sales engineer I spoke to in Atlanta las week, the software is
IDRIS, Whitesmith's UNIX look alike, none of which had yet been
dleivered to them (or any one else???), nor could he say when an
order placed for the IDRIS software for Chromatics be filled.
If color isn't mandatory and if you are willing to think about systems
with not yet ready software, ask Three Rivers whether/when the Tom Duff
port of Coherent, the Mark WIlliams company version 7 unix look-alike,
will be sold for PERQ's
--bob morris
p.s. A great deal of the Apollo software is also "not quite ready" but
they at least don't advertise it. It's just that Apollo's will presently
do much less than the world of WorkS expects them to. I will flame
after some less biased view of this week's Brown University
Apollo Users workshop appears in this forum.
Subject: Burroughs OFIS products
∂25-Jun-81 0537 Mike Leavitt <LEAVITT at USC-ISI> Burroughs OFIS products
Date: 24 Jun 1981 1748-PDT
Sender: LEAVITT at USC-ISI
From: Mike Leavitt <LEAVITT at USC-ISI>
To: works at AI
Message-ID: <[USC-ISI]24-Jun-81 17:48:50.LEAVITT>
The following is an excerpt from the New York Times, 6/23/81,
p. D5
"The Burroughs Corporation moved more aggressively into the
market for the automated office yesterday with the introduction
of a new type of information processing system that can be used
by managers and other professionals with no computer training.
"The system, called OFIS 1 Information Systems, connects
various electronic office machines together and allows them to
communicate. It includes such functions as word processing,
automatic filing and retrieval of business information and
electronic mail communications. . . .
"The system competes head-on with automated office systems
introduced in recent months by IBM, the Datapoint Corporation
and Xerox, and will be compatible with electronic equipment
made by other manufacturers. One shortcoming, according to
some analysts, is that the new system will not be able to
generate and display graphics. But the analysts were unable
to provide detailed comparisons with the competitors' systems.
. . .
"The most important innovation is a component of the OFIS
1 system called OFISfile, which permits up to 80,000 [Sic]
pages of text to be filed automatically and retrieved on
demand. OFISfile was designed to locate any document or group of
related documents with nothing more than an instruction phrased
in common English and containing a name, date, or other words in
the text being sought. . . .
"The basic OFISfile sells for $59,400, while prices for
the OFISdirector, the information processor that permits
system components to communicate with each other, starts at
$33,500. The company said that initial deliveries for the new
system are scheduled for this fall."
Burroughs?????
Mike
Subject: Re: Works: Re RIvanciw: OA Architecture
∂25-Jun-81 0600 Rivanciw at Darcom-HQ Re: Works: Re RIvanciw: OA Architecture
Date: 24 Jun 81 15:52:56-EDT (Wed)
From: Rivanciw at Darcom-HQ
To: Barns at Office-2
cc: Works at Mit-Ml, Barns at Office-2,
cc: UDel.POBox; 17 Jun 81 9:16-EDT at Office-2
Via: Darcom-HQ; 25 Jun 81 0:01-EDT
I will restate my case for the development of a systems architecture
as an early step in addressing the issue of office automation.
I will restate my position with some real world truths here at DARCOM.
It is possible at DARCOM to have office automation services for a
one time cost as low as $5634.00. That full purchase price for 100%
availability on a micro computer. Since most folks currently operate
in a timesharing mode with a multitude of user via for available ports
on a given machine, 100% availability is a step up. This price will
continue to drop as technology moves forward.
That system is based on an 8 user micro supporting 8 users. There are
8 ports on that micro so every user can run her/his office tools
whenever they want. They can currently run a host of tools including
a word processor, 3 different mail systems, a calendar system, a suspense
tool, a tickler system, a conference scheduler, a phone directory, a
reminder services, automated weekly activity reporting, and a couple
of other tools integral to the office.
Since most folks entering the realm of office automation do not use
their system for 8 hours a day, it is most acceptable that a micro with
8 user ports could easily support 16 office workers. Thus the cost
of that system is now $2817.00 one time purchase cost. On a lease that
price would be somewhere around $1000.00 or less a year cost per user
for full office automation tool usage. Now even the most pessimistic
predictions about the field of office automation would conclude that
a grand/year is very, very cost effective.
We are able to offer these cost effective systems because we have an
architecture.
As for being limited to 64K core, what micros are you looking at? The
last one I took delivery on had 1MB core. It was running a full
version 7 of UNIX plus all the software I mentioned above with 8 users.
Randy Ivanciw
Subject: Apollo files and network
∂25-Jun-81 0730 cfh at CCA-UNIX (Christopher Herot) Apollo files and network
Date: 24 Jun 1981 10:14:53-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: WorkS at mit-ai
When I last played with an Apollo a few weeks ago, it appeared
to have a hierarchical file structure very similar to UNIX.
The operating system treats local files and files on other
nodes of the ring net identically, e.g. you can copy a file
from one machine to another by typing
copy //mike/foo/bar //mary/foo/bar
and can do any file operation without respect to which machine
the file lives on. As I recall, a single slash at the beginning
of a file name indicated a pathname relative to the local node,
while two slashes indicated a pathname rooted in some master node
for the entire network. Hopefully someone at MIT, Harvard, or
Brown can elaborate (or correct).
Apollo claims that local and network file access are within
a factor of two of each other in speed. Neither appeared
particularly fast in the preliminary version I saw.
Subject: Comment on note on Apollo Network
∂25-Jun-81 0754 Dave Farber <farber@udel> Comment on note on Apollo Network
Date: 25 Jun 81 5:35:03-EDT (Thu)
From: Dave Farber <farber@udel>
To: works at Mit-Ai
The Apollo network is a token network as stated. However the
Cambridge folk are not the originators of the token ring idea. In
fact the Cambridge ring is NOT a token ring. It is a slotted ring
with small slot size.
Tokens rings come via Newhall/Farmer - the DCS process addressed
ring (the first with a real token) - the LNI/MIT LCS I ring with
the Prime ring being derived from the DCS instance.
Dave
Subject: Re: Quick overview/summary: The Apollo-I (Domain) computer.
∂25-Jun-81 0822 SHOCH at PARC-MAXC Re: Quick overview/summary: The Apollo-I (Domain) computer.
Date: 24 JUN 1981 1730-PDT
From: SHOCH at PARC-MAXC
To: DREIFU at WHARTON-10, WorkS at MIT-AI
cc: SHOCH
In response to the message sent 23 Jun 1981 (Tuesday) 2308-EDT from DREIFU@WHARTON-10
One fine point on local networks:
a) The ring produced by Prime Computer is a "token passing" design,
and it appears that the Apollo system follows this design.
Token passing systems trace their roots back to the work of
Newhall and Farmer at Bell Labs.
b) A recent message suggested that the Cambridge Ring
was also in this family; however, that design would more properly
be described as an "empty slot" ring. The empty slot systems trace
their roots back to the work of Pierce, et al., also at Bell Labs.
John Shoch
[PS: For more than you ever wanted to know on this subject, interested
readers might like to consult the "Annotated bibliography on local
computer networks, third edition," April 1980, Xerox Parc Report
SSL 80-2. Also available as IFIP Working Group 6.4 Working Paper 80-12.]
Subject: APOLLO net
∂25-Jun-81 1602 Griss at UTAH-20 (Martin.Griss) APOLLO net
Date: 25 Jun 1981 1021-MDT
From: Griss at UTAH-20 (Martin.Griss)
To: WORKS at MIT-AI
cc: griss at UTAH-20
I have seen a two node configuration of Apollo's working (Mountain View
Branch), and was able to see a file shipped from one node to the other,
and to compare the times required to count the number of lines
in the local copy and also in the remote copy, accessed via "//<host>file..".
It was interesting that in the first test, the times local and remote
were essentially; after a reboot, the remote time increased slightly
(about 5%). This was explained as an effect of the Unique global ID; in
the first test, the system "knew" the local and remote file by the same
Global ID, and also that the local copy was in the Memory space.
I do not recall the exact number of lines (it was a LARGE file), and the
time was about 1minute. The timing was done by submitting to the
SHell the concatenated commands:
time; countlines //host/... ; time; (This is NOT verbatim).
We also saw the multiple INPUT/OUTPUT windows and PADs working, the
various Display Manager options, the ability to Grow and Shrink windows,
the ability to run separate processes in each Window (in this case,
it was Edit in one, LIST in the other, as I recall).
We were not able to see any real graphics (ie line drawing), tho a small
program was demonstrated that was able to BLT screen areas around.
Martin Griss
-------
Subject: My CT system configuration and Chromatics
∂25-Jun-81 1657 Brian P. Lloyd <LLOYD at MIT-AI> My CT system configuration and Chromatics
Date: 25 June 1981 08:29-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: WORKS at MIT-AI
Bruce Daniels wrote asking about the configuration of my CT system at
home. Here is what I have:
Workstation with 256Kb RAM, 5Mhz 8086, 2xRS-232, Centronics
printer port
10Mb 8" winchester (Shugart 1004 drive)
0.5Mb 8" floppy (single side, double density Shugart 800
drive)
Soon to be added (awaiting delivery only):
Additional Workstation to be clustered on the first using CT's
local network (multi-drop, 615Kbaud, half-duplex, RS-422 line)
GE 510 300lpm printer
For software I have:
CTOS multi-task, real-time OS
Pascal
FORTRAN
Word Processor
ISAM
Forms
Sort/Merge
Multiple-window Screen-oriented text editor
Basic
and several programs of my and others design...
For those of you used to home computer prices you may find things just
a bit steep, but if you compare performance per dollar it seems to be
a fairly good deal. Price for a 128K dual floppy system is $13,300 in
unit quantities. The 256K winchester system comes in at about $21,000.
All stand-alone systems include OS (linker, assembler, screen-oriented
editor, and asynchronous terminal emulator). Additional workstations
go for $6,490 for a 128K version or $7,900 for a 256K version.
I like the system a lot. It is easier to use/develop software for
than my PDP-11/23 with RSTS/E was (I know most of you are UNIX hackers
but you have to take what you can get).
Brian
Subject: Re: Personal Workstations -- who for?
∂26-Jun-81 0604 Rivanciw.DHQ at UDel Re: Personal Workstations -- who for?
Date: 25 Jun 81 8:26:40-EDT (Thu)
From: Rivanciw.DHQ at UDel
To: JWALKER at Bbna
cc: WorkS at Mit-Ai
Subject: el.POBox; 19 Jun 81 7:36-EDT
Via: Darcom-HQ; 25 Jun 81 8:26-EDT
I agree wholeheartedly with the comments put forth in JWALKER's
message on Personal Workstations -- who for?
There currently seems to be one of two approaches taken in
applications for office automation:
(1) Develop an application that answers a specific
functional requirement. For example, a budget
preparation tool or a project management (pert)
tool. JWALKER is very right in stating that all
to often these applications are written FOR the
functional and indeed do narrowly define the scope
and processes of usually complex functions. What
results is an application that does not quite do the
job and is too inflexible to mold to the nuances
of the functional task which it attempts to address.
Bottom line is that the functional user must adapt
the way she/he does business to the application.
(2) Develop a general tool (or set of tools) that can
be used in a wide range of functional applications.
Here I am speaking of a message system, and editor,
a suspense tool, etc. While these give the functional
user much more flexibility on how she/he will use
the tool in his/he job, often this adaptation is
cumbersome. Many time we have given a message system
to a user with the response being "What can I use this
for in my job?" Then we explain how and they ask why
and we explain more and they ask how and why and....
Thus we seem once again to be telling them how to do
their business.
The folks here in are branch spent an entire day discussing this
very problem last week. What we came up with was that there is
a need for general tools AND a need for specific applications.
The problem really is that we are addressing office automation
as a tool or an application and it is really much richer than
a single tool (or set) or a single application.
What we are planning to do is to develop an office automation
system which puts emphasis on the work ENVIRONMENT. We are
going to try to structure the user's terminal like a desk.
For example, when they reach for their inbox they will end
up in the mail system. If they suddenly get a call in the middle
of reading their inbox they will not have to exit the
mail system to get to their telephone pad or calendar or whatever.
They will simply reach for it. The system will suspend processing
in the inbox and move to the telephone pad or whatever the user
wants. At the conclusion of the telephone call the user will
say something like "continue" (or hit a button) and the system
will remember where he/she was in the inbox.
In this type of environment tools and applications are transparent
to the user. They are called into use by the system, not the user.
I would really appreciate any comments or suggestions on what this user
environment should look like or include.
Randy Ivanciw
Subject: Interupting a workstation session
∂27-Jun-81 1006 Steven H. Gutfreund <SHG at MIT-AI> Interupting a workstation session
Date: 26 June 1981 14:13-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
To: WORKS at MIT-AI
cc: Rivanciw.DHQ at UDEL
I would like to comment on one part of Randy Ivanciw's letter about
the need for an integrated environment for workstations. (Which I
believe much of the world is coming around to endorsing even if they
do not know how to do).
Randy gives the example where one is reading a mail inbox and gets a call
on the phone. It would be very useful to be able to drop the mail, pick
up the phone, answer the call, and then return to one's mail.
With iconographic systems (such as STAR or SMALLTALK-80) this would be
quite simple. One would use the mouse to drag the cursor away from
the current icon (be it editor window, mail inbox, virtual terminal)
and position the cursor to the telephone icon. There one would
expand the telephone icon and answer the phone. Later one could return
to the old mail inbox icon.
However, there is a problem here that several Human Factor's people
have pointed out. That is, one could easily have quite a few "pushed"
windows, each one deep in some command dialog. The Human Factor's
people have pointed out that humans have a real scarcity of short
term memory (about 4-7 chunks). Clearly, we humans are going
to have a real problem understanding what was going on in our
workstations after a couple of interruptions.
Therefore, I would like to propogate, to designers of workstations,
a user interface folk theorem that I heard recently: NEVER HAVE
MULTIPLE LEVELS OF STATE ENCODED INTO A DISPLAY.
Naturally, I am curious as to what others feel this restriction will
do to programming a user interface. I would also be interested in
collecting other folk theorems.
- Steven Gutfreund
Subject: Shades of Nicholas Negroponte
∂27-Jun-81 1022 PRSPOOL at RUTGERS Shades of Nicholas Negroponte
Date: 26 Jun 1981 1406-EDT
From: PRSPOOL at RUTGERS
To: Rivanciw.DHQ at UDEL
cc: WorkS at MIT-AI
The second part of Rivanciw's recent comments on Personal Workstations
sound very much like the DATALAND concept of Nicholas Negroponte of the
Architecture Department at MIT. Negroponte's ideas have progressed to a
somewhat more grandiose scale. He has built a special room containing a
wall-size screen and an armchair with input controls on both the arms.
His basic concept is that people often organize themselves SPATIALLY
rather than with the alphabetic keys by which ordinary random data files
are sometimes accessed. He has described the organization of a person's
desk at the office in such SPATIAL terms.
--Peter R. Spool
-------
Subject: Tools for personal workstations
∂27-Jun-81 1040 Eric Benson <BENSON at UTAH-20> Tools for personal workstations
Date: 26 Jun 1981 1103-MDT
From: Eric Benson <BENSON at UTAH-20>
To: Rivanciw.DHQ at UDEL, JWalker at BBNA
cc: WorkS at MIT-ML
One thing we should avoid in designing tools for use by non-programmers is
condescension. Elegance of design, yes, but simple-mindedness, no. There are
three aspects I see to this:
1. It should be possible in a short period of time (perhaps less than a day,
depending on the application) to learn enough about it to be productive.
2. The expert user should be able to make maximal use of the features available
without being hampered by the requirements for (1).
3. A smooth transition from (1) to (2) should be possible.
An excellent example of this is the Tops-20 command language (EXEC). I
assume most of you are familiar with it. By combining command completion
(recognition), abbreviation and menu-on-demand, the needs of expert and
novice are served equally well.
Another example is the Emacs text editor. It is used by nearly everyone
here, including administrators and secretaries. It is possible to learn
enough in an hour to make productive use of it, then acquire facility in
advanced features (editing modes, TAGS, word abbreviations, etc.) to make
it a powerful tool. In addition, since it is programmable (all key
definitions are soft), a wizard can add features for specialized
applications. (Admittedly, no one in their right mind would use TECO as a
programming language; that was a design error not likely to be repeated.)
We don't have to choose between programs that are continually asking
Do you want to pick your nose (Answer YES or NO)?
and the arcana of Unix command names. We can have the best of both worlds.
-- Eric
-------
Subject: Languages for Distributed Workstations
∂27-Jun-81 1101 Steven H. Gutfreund <SHG at MIT-AI> Languages for Distributed Workstations
Date: 26 June 1981 12:15-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
To: WORKS at MIT-AI
cc: SHG at MIT-AI
As a researcher in local-area networks I have been quite puzzled by the
rash of comments in this digest about MESA. Many people seem to feel
that having MESA will solve their programming problems.
Personally I have found MESA to be just another member of the new class of
operating system / user environment / system programming language that is
coming on the scene. I have seen nothing that especially recommends it
for local area distributed processing (either closely coupled or loosely)
and it certainly does not have the graphics or user customizability that
a language such as Smalltalk-80 has.
I believe that the choice of which language to run on a distributed
workstation is probably the most imporant one that a workstation
ARCHITECT will make. Especially since this new class of programming
languages not only define a programmer interface, but since they
are so expansive in character and tend to want to run stand-alone
and replace the exec, they also define: the user interface, the performance
of the exec, the higher level flow control protocols, the network
wide naming conventions...
The PARC group has certainly done outstanding work in many of the
areas of research in local area network languages: name servers,
flow control, metaphors for network communication, resource allocation,
distributed file systems (Woodstock), and network servers. However,
I encourage serious students of these issues to look at what other
fine researches have done:
EPL - Experimental Programming Language, Developed at the
University of Warwick, An Actor based language, currently
in use at the University of Conn. by Ed Balkovitch.
CPascal Concurrent Pascal, Per Brinch Hansen's Language for easily
building concurrent programs such as SOLO, a simple O.S.
CSP - Communicating Sequential Processes, CAR Hoare seminal work
on abstractions for distributed parallel computing.
Aug 1978, CACM
CLU - Barabara Liskov's (MIT) concurrent programming language, intro-
duces the idea of Guardians, currently in use at MIT by
Micheal Hammer's group working on the NU machine.
?? - Distributed Processes, another Brinch Hansen lanaguage for
concurrent distributed. Nov 1978 CACM
Act1 - One of the numerous Actor Languages from Carl Hewitt (MIT)
Edison Per Brinch Hansen's latest language on for multi-computer
systems.
*Mod - Modula based language being used at University of WISC in
their distributed programming project.
Actors Viewing Control Structures as Patterns of Passing Messages,
MIT AI Memo 410. Carl Hewitt's paper on Actors, Some of the
most difficult reading to be found.
DC-Pascal Distributed Concurrent Pascal, this is a language I developed,
which tries to be a fusion of the above mentioned languages.
I have not even begun to cover the full scope of literature. Clearly
this is an active area for reseach, and clearly there will be more
papers since there are plenty open areas for research.
- Steven Gutfreund
Subject: system architecture
∂27-Jun-81 1124 Rivanciw.DHQ at UDel system architecture
Date: 26 Jun 81 15:20:27-EDT (Fri)
From: Rivanciw.DHQ at UDel
To: works at Mit-Ai
cc: Rivanciw.DHQ at UDel
Via: Darcom-HQ; 26 Jun 81 16:29-EDT
Peter Deutsch requested that I send along a short summation of
DARCOM's system architecture for OA (in particular hardware, software)
so here goes.
The software that DARCOM is running in its OA architecture is UNIX.
Right now we have some v6, some pwb, and some v7. We will standarize
on the latest release of UNIX from BELL. Our tools are currently all
in the public domain except for an office package that we have running
on our HQ machine called OPUS. The public domain software includes
NED, ED, MSG, MS, and (I think its public) XMSG, as well as some
home grown tools such as a suspense program (which is really a shell
routine) and an automated weekly activity report.
The hardware for our architecture is simply any machine that runs
UNIX. Currently we have 11/70s and ONYXs operational. We are
looking into the C machine from BBN. Of course we are interested in
the latest announcement on ZENIX (Unix look alike for any 16-bit
micro).
Randy
Subject: Mini/Micro Systems June 1981
∂27-Jun-81 1138 KESSLER at UTAH-20 (Robert R. Kessler) Mini/Micro Systems June 1981
Date: 26 Jun 1981 0743-MDT
From: KESSLER at UTAH-20 (Robert R. Kessler)
To: Works at MIT-AI
Two possibly useful articles:
"Xerox 'Star' shines on professionals", page 23 and
"Novell's Nexus addresses work-station market", page 99.
Bob.
-------
Subject: Re: Xerox Dolphin (alias 1100⊗?)
∂27-Jun-81 1151 Chris Ryland <RYLAND at SRI-KL> Re: Xerox Dolphin (alias 1100⊗?)
Date: 26 Jun 1981 1200-PDT
From: Chris Ryland <RYLAND at SRI-KL>
To: TEITELBAUM at RUTGERS
In-Reply-To: Your message of 25-Jun-81 1836-PDT
Yes, the Dolphin is being sold by XEROX EOS as the 1100 "Interlisp Machine."
It is about $60K, last I heard (someone at Rand or ISI correct me here.)
It is also about 3 times as slow as the Dandelion (what's inside the Star),
according to very reliable people at PARC; that is surprising, since the
Star costs little by comparison ($6K in parts costs, I've heard.)
Also, XEROX is now putting up Smalltalk on the Star, for internal use.
I have no idea, and I suppose neither does XEROX, if they'll ever release
it.
-------
∂27-Jun-81 1204 Newman.ES at PARC-MAXC Re: Xerox Dolphin (alias 1100⊗?)
Date: 26-Jun-81 12:12:38 PDT (Friday)
From: Newman.ES at PARC-MAXC
Subject: Re: Xerox Dolphin (alias 1100⊗?)
In-reply-to: TEITELBAUM's message of 25 Jun 1981 2136-EDT
To: TEITELBAUM at RUTGERS
cc: works at MIT-MC, archer at SU-SCORE
Looks like a true rumor to me. The following is excerpted from a PARC Forum
announcement sent to all users of the Xerox message system. It was an open
forum, so this is public information.
-----
The Xerox 1100 Scientific Information Processor, currently being marketed by
Xerox EOS to the research community, is a Dolphin processor running
Interlisp-D. Not only does this configuration provide comfortable
interactive performance, but the availability of Interlisp on such a low cost
machine makes economically viable the widespread use of knowledge based
technology, such as the deployment of intelligent servers in a distributed
network environment.
-----
(Xerox EOS = Xerox Electro-Optical Systems of Pasadena, Calif.)
The "Dolphin" is the same processor used in the Xerox 5700 laser printer.
This is NOT the "Dandelion" processor used in the Xerox Star.
/Ron
∂27-Jun-81 1221 mike at RAND-UNIX Re: Xerox Dolphin (alias 1100⊗?)
Date: Friday, 26 Jun 1981 11:10-PDT
To: TEITELBAUM at RUTGERS
Cc: works at MIT-MC, archer at SU-SCORE
Subject: Re: Xerox Dolphin (alias 1100⊗?)
In-reply-to: Your message of 25 Jun 1981 2136-EDT.
From: mike at RAND-UNIX
The Xerox SIP 1100 (Scientific Information Processor 1100) is really
going to be marketed by Xerox EOS (Electro Optical Systems). Here's
the deal:
It will sell for $60,000 a copy
It will have Interlisp. It will not have Mesa. It will not
have Smalltalk. (Maybe later it will, but they are not
promising it today).
It will have the 3mbit Ethernet. 10mbit later, but not this
year.
They wont sell any unless they get 'some minimum number of
orders'. The number that is most often mentioned is 40. (That
is, 40 altogether, nationwide. Not from one customer.)
The kind of maintenance available depends on where you live.
If you are not in LA or Palo Alto, then you will probably have
to do maintenance by paying time, materials and travel. The
other possibility is to stock spare parts and swap boards.
XEOS is considering, and would prefer, to have a complete
maintenance organization if there is the interest and enough
Dolphins in one place.
This deal is taking place because, among other reasons, ARPA
is looking for a way to get personal, networked Interlisp
machines to some of their researchers.
Xerox is accepting purchase orders now.
Let me know if you want a phone number for a Xerox contact. Your
local sales organization will probably not be of any help.
Michael
Subject: Personal Workstations
∂27-Jun-81 1240 Rivanciw.DHQ at UDel Personal Workstations
Date: 25 Jun 81 9:08:01-EDT (Thu)
From: Rivanciw.DHQ at UDel
To: works at Mit-Ai
Via: Darcom-HQ; 25 Jun 81 9:01-EDT
In Kevin Dowling's message of 18 June he mentioned that "the
people on this list are probably not the market that Xerox is
aiming for (as opposed to the business community)". This makes
me wonder - who are the people on the personal workstation
mailing list? It might be a good idea to kind of introduce
ourselves to each other. Like the quote goes:
"Where a man stands usually depends on where he sits"
I am Randy Ivanciw, a computer specialist with the US Army
Development and Readiness Command (DARCOM). My major duties
include long range and short range planning for office automation.
I work at DARCOM headquarters (I am a civilian) as a member of
a 7 person staff dealing with the use, planning, implementation]
and other nasties of office automation.
Randy
[ If you would like to put in a brief description of who you
are and what your professional interest in this list is, we
will be happy to organize the responses for distribution in
an appropriate manner. A special mailbox has been established
to simplify the problem of collecting this material. Please
address your descriptions to WorkS-Census@MIT-AI. Thank you. ]
Subject: The Economics of Workstations
∂29-Jun-81 0747 WMACGREGOR at BBNA The Economics of Workstations
Date: 29 Jun 1981 0905-EDT
From: WMACGREGOR at BBNA
To: works at MIT-AI
cc: BTHOMAS at BBND, SCHANTZ at BBND
The commercial success of the personal workstation is largely a
matter of economics. Irrespective of the technical merits of the
various machines, they complicate installation planning by introducing
a new type of capital expenditure which typically cannot be financed
the same way as large, centralized computing centers of the past.
This may be an advantage or a disadvantage, depending on your point of
view.
On the negative side, the incremental cost of placing one new
user on a personal workstation is very large--the cost of the
workstation plus a local network interface and cabling, at least. For
centralized systems, the cost of adding one user to the community is
the price of a terminal and a terminal port (which is often dial-up,
and amortized over many users). Certainly there are many hidden costs
involved in either case, for example, the degradation of performance
of the centralized system as the user community expands; nonetheless
the capital expense of the physical equipment represents a fundamental
barrier, an "activation potential" if you will, for new users.
Are we making good use of the technology? From one point of
view, the development of personal workstations has been directed
towards increasing the computing power available to individual users
(the "KA-10 in your office" philosophy), at roughly constant or even
increasing capital cost per user. Can comparison shopping in the
small systems marketplace, a highly competitive part of the economy,
be a better idea in some cases?
In particular, I remember one reader of this list commenting to
the effect that he wasn't interested in small systems (e.g., micros
with 16-bit address spaces). I use an H89 (Z80 based system, 48K
bytes of RAM, 5" floppies) at home, and for the sake of comparison I
ran the Baskett test on this machine. I transliterated the program
into C for the C/80 compiler as directly as possible (almost token for
token), and even on the "small" system the object code is only of
modest size. The execution time was 542 seconds, as opposed to about
40 seconds for the Perq. This Z80 machine runs at a 2 MHz. clock,
which can easily be doubled to 4 MHz. reducing the run time to 270
seconds, about 6 times slower than the Perq.
I do not mean to suggest that we should all be using CP/M and
8-bit micros. But neither does it seem wise to pass over these "small
workstations" as being insufficiently powerful; they can be extremely
cost effective. The question is not whether these systems should be
used at all, but how they might be integrated into larger
environments. Suppose a user can afford to pay $3000 (about twice the
cost of a terminal) for a VT-103 (a VT-100 terminal plus LSI-11
processor). What functions can we place in this device to improve
performance? How should it be integrated into the network of personal
machines and shared hosts? Could we, for instance, support a window
package for the VT-100? (In fact, we can; examples already exist.)
From my experiences at BBN, it is clear that the economics of
personal workstations can be very complicated. Two troubling effects
that may be general phenomena are the sharing of one "personal"
machine by several people (and corresponding problems of data
security, authentication, etc., which have been pretty much ignored in
the "personal" workstation model), and the inability of low budget
projects to get into the game at all (it is difficult for people on
different projects to share the same machine, for many reasons).
I would be interested to learn how others are resolving these
issues, whether in software or by direct administrative control.
- Bill
-------
Subject: Interupting a workstation session
∂29-Jun-81 0825 Daniel L. Weinreb <dlw at MIT-AI> Interupting a workstation session
Date: 28 June 1981 22:11-EDT
From: Daniel L. Weinreb <dlw at MIT-AI>
To: SHG at MIT-AI, WORKS at MIT-AI
I agree that it is hard for a user to keep track of a stack of
interruptions. Having to maintain a mental model of such a stack, and
having to remember what "exit this command level" will do, is a real
pain. Most interactive systems I have used have suffered from this
problem. The Lisp Machine solves the problem by having all of the
user's activities be at the same "level". There isn't any command
processor that "calls" programs which then "return" to the command
processor; you just move "sideways" from one thing to another. No
stacks are involved. (Actually there are still a few stacks in the
system, but they are being removed.) (There are some commands that mean
"switch back to the previous thing I was doing", which you sometimes
want, but nothing forces you to use these commands. (If you gives such a
"previous thing" command over and over, it switches between the same two
things, in case you were wondering.))
Not only is this easier to use, but it is more powerful. If you are
reading your mail and you are interrupted by a phone call, you can go
handle the phone call, and then put the caller on "hold" and go back to
reading your mail, and then get back to the phone call. That is, you
need not maintain a last-in first-our ordering among your actitivies.
This is one of the things I think is most valuable about the Lisp
Machine's overall user interface structure.
Subject: Re: Tools for personal workstations
∂29-Jun-81 0848 mike at RAND-UNIX Re: Tools for personal workstations
Date: Saturday, 27 Jun 1981 12:19-PDT
From: mike at RAND-UNIX
To: Eric Benson <BENSON at UTAH-20>
Cc: Rivanciw.DHQ at UDEL, JWalker at BBNA, WorkS at MIT-ML
In-reply-to: Your message of 26 Jun 1981 1103-MDT.
Eric Benson's message implicitly compares the Emacs design with UNIX.
In his words, Emacs is elegant, UNIX arcane.
And that Emacs should be a guide for future designers !
And a merry,
CONTROL META SHIFT FOO
to all of you, too.
Michael
Subject: frisbees and floppies...
∂29-Jun-81 0911 Daniel L. Weinreb <dlw at MIT-AI> frisbees and floppies...
Date: 28 June 1981 21:15-EDT
From: Daniel L. Weinreb <dlw at MIT-AI>
To: SK at MIT-MC
cc: WORKS at MIT-AI
You asked, "The instantaneous bandwidth of such a transmission system is
very high. So who needs a Chaosnet?" This was presumably in reference
to the use of floppy disks for inter-workstation file transfer.
While the instantaneous bandwidth may be the same, the overall bandwidth,
counting the playing with the physical disks, is much lower.
Furthermore, the net is superior because (1) you can't do remote login
over floppy disks, nor asking what time it is, nor asking who is logged
in, nor anything else besides file transfer, and (2) it is very clumsy,
especially if the other machine is across the street or down the block.
Direct and easy access to a shared file server is important.
Subject: Addressing and File Accessing
∂30-Jun-81 0205 Barns at OFFICE Addressing and File Accessing
Date: 29 Jun 1981 0544-PDT
From: Barns at OFFICE
To: WorkS at MIT-ML
cc: Barns
The recent discussions of address space size, remote file access, etc.,
brought back to my mind the IBM System 38 - specifically the notion of
only one kind of addressing (48 bits in that machine) which is used
to access "main memory" or data on secondary storage - rather than
having files, there is the notion of various "access paths" possibly
existing through a great heap/swamp/"data base" of bits and bytes.
As far as I know the machines under discussion generally belong to the
Multics/Tenex/Unix school of thought that on the one hand, there is
memory, and on the other hand, there are files. All sorts of nasty things
like networks, terminals, users, etc., are mapped into one of the two
(usually files). But it seems to me more desirable (in principle at least)
to have only one kind of thing ala S/38, with various notions of access
paths, objects, classes of objects, etc.
I for one would be interested in knowing if my feeling is shared by
others, and also whether there are any plans on the part of the research
groups or other entrepreneurs to build such machine/software combinations
for those of us who would rather not program in RPG.
Bill Barns
-------
Subject: Re: el.POBox; 19 Jun 81 7:36-EDT
∂30-Jun-81 0222 Deutsch at PARC-MAXC Re: el.POBox; 19 Jun 81 7:36-EDT
Date: 29 Jun 1981 09:58 PDT
From: Deutsch at PARC-MAXC
In-reply-to: Rivanciw.DHQ's message of 25 Jun 81 8:26:40-EDT (Thu)
To: Rivanciw.DHQ at UDel
cc: JWALKER at Bbna, WorkS at Mit-Ai
The Xerox Star terminal interface is structured exactly the way
you suggest -- it gives you a "desktop" of capabilities which
(subject to the space limitations of the screen) you can "reach
for" at any time.
Subject: Multiple Levels Of State
∂30-Jun-81 0244 Rivanciw.DHQ at UDel Multiple Levels Of State
Date: 29 Jun 81 9:41:58-EDT (Mon)
From: Rivanciw.DHQ at UDel
To: works at Mit-Ai
Via: Darcom-HQ; 29 Jun 81 12:27-EDT
In Steven Gutfreund's recent message on user environments he mentioned
that it would be best to "NEVER HAVE MULTIPLE LEVELS OF STATE
ENCODED INTO A DISPLAY". I am not quite sure what Steve is really
going for here - does this mean never to have more than one level
on a screen at any given time? or does this mean not to have the
system track where and what a use was doing? I am not sure.
My thought are that in my work environment I am constantly being
interupted by phone calls, urgent messages (electronics as well
as paper), and drop in visits. Often times I can not remember
where I was or what I was doing (Steve mentions this problem in
his message). It was my hopes that an office system could help
me keep track of where I was and what I was doing.
For example, right now I am composing a message to the WORKS
mailbox. Suddenly an urgent electronic message header comes up
on my screen that I must answer right now. I abort this message
(naturally saving the draft) and read the new message, check other
files (calendar, saved messages, suspenses, etc) and compose a
reply. That might take 15 minutes. In the meantime my phone
rings or I have to make a call that requires me to divert my
attention elsewhere. Then someone stops by my desk to tell me
about their weekend or talk about some configuration.
Bottom line is that I forget all about this message. I simply
did not remember where I was or what I was doing. Several days
from now I'll see a file named DRAFT-WORKS and wonder what it
is. I'll read the file into the editor and suddenly remember
what I was doing, but by then the reply may not be worthwhile.
In a very rich user system, the system would keep trach of where
I am so that when I said continue it would take me back to this
message reply and I can finish it. I feel that this tracking
would have to go at least 3 or 4 levels deep.
What are some other thoughts?
Randy Ivanciw
Subject: Re: Tools for personal workstations
∂30-Jun-81 0303 Eric Benson <BENSON at UTAH-20> Re: Tools for personal workstations
Date: 29 Jun 1981 1232-MDT
From: Eric Benson <BENSON at UTAH-20>
To: mike at RAND-UNIX
cc: Rivanciw.DHQ at UDEL, JWalker at BBNA, WorkS at MIT-ML
Mike's response (more like a Bronx cheer) forces me to clarify some of the
points I was trying to make:
First, I could not say that the design of Unix is not simple, clean and
well-integrated from top to bottom. In fact, I only objected to one thing,
certainly not a central point, which is the cryptic command names (cat, mv,
rm, sh, ls, grep). These are almost as mnemonic as PDP-10 opcode names.
(Jrst enough for some, I suppose.)
Second, Emacs is no Mies van der Rohe creation. The implementation is at
three levels, MIDAS, TECO, and Emacs keyboard input, the first two of which
are incompatible with each other and sane human beings. The single
character commands are also cryptic, but there is readily accesible online
documentation for them. Common editing commands are often used in rapid
succesion, necessitating brevity. (Although I believe I saw an editor
described in Software P & E using the Tops-20 COMND JSYS which looked
somewhat interesting for novices.) Mike (apparently) objects to the use of
extra shift keys for commands. This is required because there is no
"insert mode" in Emacs; what you see is what you get. That is what
distinguises it from every other editor I have used, and is the most
important aspect of its design. Also, by not requiring special editing
keys or other input devices such as a mouse, a good typist can remain in
registration when entering commands.
Unix was designed when CPU power, memory, address space and terminal
bandwidth were scarce resources. Its popularity (in academic circles) is
due to its accessibility, portability and malleability. I only hope
in extolling its virtues we do not overlook its shortcomings.
-- Eric
P.S. Sorry for getting a little off the topic of personal workstations per
se, but I believe this is relevant to system design.
-------
Subject: On productive text editors, suggested reading includes
∂30-Jun-81 0319 DREIFU at WHARTON-10 (Henry Dreifus) On productive text editors, suggested reading includes
Date: 29 Jun 1981 (Monday) 1448-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: works at MIT-AI
this month's SIGPLAN (#6) on the Text-Manipulation conference conducted
earlier this year. It goes into some detail (Yale's "Z" envr for exmpl)
on how some systems were put together, and what benefits they provide to
the work-area.
Hank
Subject: ALANTHUS System 1000 workstation
∂30-Jun-81 0330 Edward Kozel <EKozel at SRI-KL> ALANTHUS System 1000 workstation
Date: 28 Jun 1981 1236-PDT
From: Edward Kozel <EKozel at SRI-KL>
To: WorkS at MIT-AI
I have some literature on the ALANTHUS System 1000 workstation. It is
a 16-bit machine with high resolution display (15"), up to 1M of RAM,
and a set of either twin 8" floppies or a winchester drive. It is
configured in an interesting manner, with the "guts" (RAM, controller,
etc.) in a chassis sitting upright on the desk with a clipboard on
the3 side to disguise the box. This allows the entire system to be
off the floor (excepting mass store, which can be across the room).
They claim the desktop units can be lined together via a high speed
LAN, providing multi-station access to shared resources. They are
on the Federal Supply Schedule, which (I assume) lends some
respectability to the enterprise. They use both the Intel 8086
and 8088 in their various configurations.
Sounds like they are using Convergent Tech gear. Does anybody know
otherwise?
Ed Kozel
-------
Subject: Re: Xerox Dolphin (alias 1100⊗?)
∂30-Jun-81 0353 Deutsch at PARC-MAXC Re: Xerox Dolphin (alias 1100⊗?)
Date: 29 Jun 1981 09:55 PDT
From: Deutsch at PARC-MAXC
In-reply-to: TEITELBAUM's message of 25 Jun 1981 2136-EDT
To: TEITELBAUM at RUTGERS
cc: works at MIT-MC, archer at SU-SCORE
Your information is correct. The Xerox 1100 is a Dolphin with
Interlisp. Its speed is approximately 1/2 KA-10 equivalent,
assuming you buy enough memory (~ 1 MByte) so that paging doesn't
kill you. It comes with a 600 x 800 bitmap display, a 28 Mb
non-removable disk, and a mouse; I'm sure some flavor of Ethernet
will also be available. I have no information on purchase price,
delivery schedule, etc. as yet.
Subject: Xerox 1100 (Dolphin)
∂01-Jul-81 0257 DEUTSCH at PARC-MAXC Xerox 1100 (Dolphin)
Date: 30 JUN 1981 1335-PDT
From: DEUTSCH at PARC-MAXC
To: WORKS at MIT-AI
I inadvertently quoted the 1100 speed for Interlisp as 1/2 KA-10.
The correct figure is 2 KA-10. The standard configuration being sold
includes roughly 1.2 MByte memory and a network connection.
For further details (including price, availability, options, etc.),
people should contact Marcel Pahlavan in Xerox EOS at (213)351-2351.
Some people in Xerox management are understandably a little concerned
that some busybody might narrow-mindedly disapprove of the use of the
ARPANet for discussion of a commercia\ product, although I don't see
how an informed discussion of personal workstations can proceed in the
absence of quite detailed information (technical and`otherwise).
Subject: ALANTHUS System 1000 workstation
∂01-Jul-81 0321 Brian P. Lloyd <LLOYD at MIT-AI> ALANTHUS System 1000 workstation
Date: 30 June 1981 08:45-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: WORKS at MIT-AI
Alanthus is indeed selling the Convergent Technologies system. There
are now three flavors of workstation: the Integrated Workstation
(IWS), the Monitor Workstation, and the Applications Workstation. The
IWS and MWS are electrically identical with the difference being that
the processor is remoted into a box like the mass storage. Only the
display and keyboard remain on the desktop. The Application
Workstation (AWS) is the "low cost" workstation and physically
resembles the IWS. The AWS is based on the 8088 (instead of the
8086), has fewer bells and whistles (no serial/parallel I/O, font
fixed in ROM, etc.), and has no Multifus expansion. The advantage of
the AWS is that it is about half the cost of the IWS and suddenly the
cost-per-workstation falls into the $5,000 range. The AWS can run all
of Convergent's software with the exception of the Font Designer.
Brian
Subject: Clarifications about interrupting workstaions
∂01-Jul-81 0334 Steven H. Gutfreund <SHG at MIT-AI> Clarifications about interrupting workstaions
Date: 30 June 1981 1p:52-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
To: WORKS at MIT-AI
cc: DLW at MIT-CI, rivenciw.dhq at UDEL
Re: Clarifying my comments on Interrupting workstation activity
I tend to aoree with Daniel Weinreb's comments about the need
to structure the user interface so that one can move gracefully
"side-ways" between windows/activities. He states that the
ability to movc "side-ways" was lone by the removal of calling
or nesting of routines.
This nesting of dialog or routines is what I am trying to point
out as a danger area for system designers. If one allows
a designer to create an arbitrary state machine by means of a
protracued dialog, then the user will be required to read the
entrails of his display to try and reconstruct the dialog that
occured earlier when he interrupted his session.
Randy Ivanciw is gorrect when he says that a system could be
built which would "refresh" the user's memory when he returns
to a window. However the problem with arbitrary state diagrams
in dialogs is that such a smart assitant would have to understand
all transitions that a user could have made. Pre-designing
such help into a dialog is a massive chore, and therefore rarely
done well or done at all.
It seems to me that if one is to follow the old maxim: WHAT YOU
SEE IS WHAT YOU GET. Then we should not have state diagrams in
dialogs which cause the user to be able to read the entrails of
his/her display to figure out what has gone on before he/she
left a window.
- Steve Gutfreund
Subject: Re: Multiple Levels Of State
∂01-Jul-81 0344 Deutsch at PARC-MAXC Re: Multiple Levels Of State
Date: 30 Jun 1981 12:52 PDT
From: Deutsch at PARC-MAXC
In-reply-to: Rivanciw.DHQ's message of 29 Jun 81 9:41:58-EDT (Mon)
To: works at Mit-Ai
Whoever mentioned the MIT Lisp machine solution hit the nail on the head: if
(1) there is no notion of "nesting" of suspensions, but rather simply a pool of
tasks in various stages of completion which the user can switch between at will,
and (2) every partially completed task is represented by a VISIBLE OBJECT on
the screen, then there is no issue about forgetting partially completed tasks,
being forced to complete them in the order they were started, etc., etc. I believe
(at least I hope) the Star works this way, since all the experimental
multi-window systems at PARC do.
Subject: Question to field: Bit Mapped displays
∂01-Jul-81 0353 DREIFU at WHARTON-10 (Henry Dreifus) Question to field: Bit Mapped displays
Date: 29 Jun 1981 (Monda{) 2210-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: WorkS at MIT-AI
o BIT Mapped displays.
Would anyone care to discuss what is a bitmap as oppsoed to
a raster-bitmap, as opposed to a whatever? I am certainly no expert
in this area, and the "Display" seems to be a key feature of most
Perscoms today.
Henry Dreifus
Subject: Addressing and File Accessing
∂01-Jul-81 0403 Vaughan Pratt <CSD.PRATT at SU-SCORE> Addressing and File Accessing
Date: 30 Jun 1981 1033-PDT
From: Vaughan Pratt <CSD.PRATT at SU-SCORE>
To: works at MIT-ML
I couldn't agree more with Bill Barns. Simplifying storage organization
is an important aspect of the more general goal of simplkfying the
user's perception of what is of necessity a very complex environment.
There is some support at Stanford for this goal; in particular we would
like to be able to offer users of SUN (Stanford University Network) a
simple coherent model of both SUN and (a rough approximation of) the
world outside SUN. Some vague thoughts along those lines appear in
<CSD.PRATT>SUNUI on Score. Brian Reid and I are mulling over such
ideas during this summer.
-------
Subject: Re: File accessing?
∂01-Jul-81 0413 DREIFU at WHARTON-10 (Henry Dreifus) Re: File accessing?
Date: 30 Jun 1981 (Tuesday) 2023-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: csd.pratt at SU-SCORE
cc: works at MIT-AI
And`what about providing parallel alternative file systems for
differing applications. Eg: Stream where Stream is good, and
chav where character is good (pipes). Make each system consistent
within itself and transparent to the end user. The system
developer can choose the file TYPEs s/he would be able to use
the most efficienly and blasto.
Hank
Subject: Re: Addressing and File Accessing
∂01-Jul-81 0428 host MIT-ML Re: Addressing and File Accessing
Date: 30 June 1981 11:46 edt
From> Frankston.SoftArts at MIT-Multics
Sender: COMSAT.SoftArts at MIT-Multics
Reply-To: Frankston at MIT-Multics (Bob Frankston)
To: Barns at Office-2, WorkS at MIT-ML
*from: BOB (Bob Frankston)
Local: Barns at OFFICE,WorkS at MIT-ML
Poor Multics. People seem to attribute all the limitations of
its imitators to the original. One of the major advances in
Multics was its large address space and the uniform treatment
of the address space. Files are not an intrinsic part of
Multics -- only a convention for access memory through I/O
routines. There isn't even I/O -- just a set of conventions
for writing for writing an I/O interface module.
Yes, the system/38 does work out a lot of the ideas and I still
feel it is IBM's most advanced system and have suggested people
look at it as a model. But from what I hear it has not solved
its performance problems, though the model of using gobs of
computational power to provide a powerful interface is the
correct one.
The other difference is that Multics provides the full power of
its process to its users. The System/38 is packaged like a
real computer but seems to be much closer to an assembly
language/PLS interpretter running the user code. It was clever
to invent the term vertical microcode, it means that they don't
need to give you a listimg of the operating system and are free
to change the internals as long as they preserve the user
interface.
Overall I think that the System/38 is a winner and one day IBM
will tell people that it is more than a System/34 upgrade. On
the other hand, I have not used it directly and RPG III (a VHLL
production language if you want to look at it that way) is the
only language currently available. It is also a little on the
expensive side, even compared to a Star.
Subject: Errata on Barns message "Addressing and File Accessing"
∂01-Jul-81 0445 The Moderator <WorkS-REQUEST at MIT-AI>
Errata on Barns message ''Addressing and File Accessing''
Date: 1 July 1981 07:00-EDT
From: The Moderator <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
Original statement:
As far as I know the machines under discussion generally belong
to the Multics/Tenex/Unix school of thought that on the one hand,
there is memory, and on the other hand, there are files.
-- Barns at OFFICE
Comments:
Multics does not view files as something fundamentally different
from memory. Rather, it was the first system to support a uniform
single-level memory system consisting of variable size objects
(segments) from 4096 bytes to 1 megabyte in length. Files were
simulated in Multics for compatibility reasons only, and files
were constructed out of segments.
-- Paul A. Karger <PAK at MIT-MC>
An important correction for all of you who have never used Multics,
and are constantly assuming that it is like UNIX or TENEX. It is
not. Barns, for example, says that Multics/TENEX/Unix differentiate
between files and memory (and that the S/38 doesn't). Multics was
the first system to do away with the concept of file--Multics "files"
are merely part of its large virtual memory, and are accessed via
pointers. S/38 has few new ideas in this area, and a lot of crocks.
Pish tush. -- DPR at MIT-XX
You are completely wrong in classifying Multics in this group.
In Multics, there is absolutely no distinction between "memory"
and "files"; there are just segments, which live in a hierar-
chical file system and are addressed directly. The System 38
is a spiritual decendant of Multics in this regard.
Just because an idea is old-fashioned does not mean you should
identify it with Multics. For all Multics's problems and extreme
age, it is STILL ahead of its time in some ways. Sorry for the
irrelevance of this message, but I couldn't just let this go by...
-- Daniel L. Weinreb <dlw at MIT-AI>
Subject: Storage Question Restated
∂03-Jul-81 0806 Barns at OFFICE Storage Question Restated
Date: 1 Jul 1981 0628-PDT
From: Barns at OFFICE
To: WorkS at MIT-AI
cc: barns
Now that half the Multics users in the world have voiced their
displeasure, let me try to say what I was really trying to say
before, hopefully in a less offensive manner:
During the time period when Multics was born, that system
and others made varying uses of the idea of a single level
store. Naturally different people came up with different
hardware/software approaches and solved different subsets
of the universe of possible situations. Since then we have
had Tenex and Unix which have made their own contributions,
and also some steps backward because of the desire to make
something that doesn't chew up a disproportionate share of
a timesharing system's time. (Yes, many others too, but
Tenex and Unix are perhaps best known.) More recently the
S/38 has attempted to go back to some of the more general
ideas, which is noteworthy in that it is not such an enormous
processor, nor is it intended to be a timesharing system of
the flavor of Multics or Tenex or Unix. Unfortunately there
are also many unfortunate things about the 38 as now packaged
- notably the lack of programming languages that many of us
like to use, or reasonable substitutes.
Now it is my impression (unsupported by hard data) that the
38's processor is more or less in the same ballpark as (some
of) the workstation processors. This suggests that it is
not unreasonable for someone who has a mind to, to make a
programming environment on these machines, or ones like them,
which will give us a simple means of accessing data for the
purpose of local computation by the 'owner' of the workstation
and only apply restrictions on access to people elsewhere in
a network. I suggest that in the nicest form, this means that
the workstation's programs access things by an n-bit number
which is absolute for the whole workstation. This need not
mean that no other form of accessing can exist.
The question, then, is, What such things exist or are planned?
To date the responses indicate that the Lisp Machine has such
an organization and that the Perq will at some future date have
a virtual storage box to support such things at the firmware
level. Dan Lynch's message of sometime back suggests that the
STAR does its storage paging in a nasty way, not clean at all,
but details seem to be unknown outside Xerox. Anybody know
any more?
--Bill Barns
-------
Subject: Re: Addressing and File Accessing
∂03-Jul-81 0954 Chris Ryland <RYLAND at SRI-KL> Re: Addressing and File Accessing
Date: 30 Jun 1981 1131-PDT
From: Chris Ryland <RYLAND at SRI-KL>
To: Barns at OFFICE-2, WorkS at MIT-ML
In-Reply-To: Your message of 29-Jun-81 0544-PDT
Bill, the system you describe (System 38) is just a
capability-based machine, which is certainly old hat by now.
Unfortunately, this idea still seems to be barely catching on in
the "real world." Most of the seminal systems (CAL at Berkeley,
Hydra at CMU, and the Plessey System 250) were done and finished
years ago, and yet there are only a few commercial systems which
reflect this elegance of architecture (S38, Intel's 432 (in some
sense), some ICL machines). Others are working on systems which
embody these ideas (H-P's Bridge project, the S-1 project), but
most of them bastardize the design for "practicality". I surmise
that capability-based systems are finding life difficult because
no one ultimately understands how to deal with them practically
(e.g., the Hydra folks discovered quite a few problems with
accounting (who owns an object?), backup, recovery, etc., though
they also made great strides with some of the harder issues
(mostly reliability).) I think a large percentage of us would
be delighted to have a true capability-based machine if the
performance were up to what we've come to expect from current
architectures, but that doesn't seem to be around the corner (at
least in any useable way: S38 hides all its good design from the
user and masks it in the usual nonsense IBM business software.)
-------
Subject: Re: Question to field: Bit Mapped displays
∂03-Jul-81 1034 cfh at CCA-UNIX (Christopher Herot) Re: Question to field: Bit Mapped displays
Date: 3 Jul 1981 08:47:25-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: DREIFU at WHARTON-10
Cc: WorkS at MIT-AI
In response to your message of Thu Jul 2 20:26:38 1981:
Bit Map refers to the way a picture is stored, i.e. one
bit (or aggregate of bits for color) of memory for each
addressable point on the screen. As opposed to the older
"display list" technique where the picture is stored as a
list of line segments, etc.
Raster-scan refers to the method by which the picture is
refreshed on the screen, in this case, as a series of
horizontal lines, starting at the top of the screen and
moving down. As opposed to "stroke writers" which move
the beam in arbitrary directions to draw individual
graphic primitives.
The earliest displays were stroke writers. The TX-0 at MIT
moved a beam on a CRT under the direct control of the CPU.
In some sense, this was the first personal computer, as
refreshing the display didn't leave too many cycles for
anything else. Later, the direct view storage tube (DVST)
allowed the picture to be written just once instead of
being refreshed 30 or more times per second. Only problem
was that the only way to change anything on the screen was
to erase the entire screen in a blinding flash which took
.5 seconds. By the way, contrary to current publicity about
the STAR, the Advanced Remote Display Station (ARDS) storage
tube terminal was the first to offer the "mouse" as an input
device.
Stroke writers are still in common use in the CAD/CAM area.
They typically employ high-performance (expensive) analogue
circuitry to draw vectors of much higher resolution than are
currently feasible with raster displays. Resolutions of
4096x4096 are not uncommon.
The raster scanned bit map display is rapidly taking over
the display scene. It is cheaper to build circuits which
move the beam in nice sraight lines across the screen than
to build in the ability to turn corners.
To answer your question, for all intents and purposes,
raster-bitmap and bitmap mean the same thing.
-----
Subject: capability machines
∂04-Jul-81 0915 HGBaker.Symbolics at MIT-Multics capability machines
Date: 3 July 1981 14:15 edt
From: HGBaker.Symbolics at MIT-Multics
To: ryland at SRI-KL, works at MIT-AI
1. A capability is just a fancy name for a pointer in a
machine that doesn't have enough address space to begin
with.
2. The current hangup of capability machines is their
unwillingness to do garbage collection. (Tracing, etc.,
that is.)
3. Lisp was the first capability machine. It is true that
the objects are quite small in the original Lisps, but
with newer Lisps having vectors, strings, objects,
classes, flavors, and what have you, they have all the
power of Hydras, 432's, etc.
Subject: Re: Addressing and File Accessing
∂04-Jul-81 0945 Deutsch at PARC-MAXC Re: Addressing and File Accessing
Date: 3 Jul 1981 14:50 PDT
From: Deutsch at PARC-MAXC
In-reply-to: RYLAND's message of 30 Jun 1981 1131-PDT
To: WorkS at MIT-ML
I must be missing something. Barns wishes for "an n-bit
number which is absolute for the whole workstation". Isn't
a reasonable-size conventional virtual address a solution to
this problem, provided that the operating/language system
doesn't allow you to fabricate addresses? That's the only
sense in which the Lisp Machine solves the problem, and it
only does it by virtue of NOT having any local capability
for named files. The LM doesn't provide any facilities
that replace a local file system, either, e.g. there are
no tools in the system for constructing and manipulating
directories of variables. Furthermore, the LM would be
helpless without the presence somewhere in the network
of some very conventional file systems which handle messy
questions like space accounting, periodic backup, user
authentication, etc.
Of course, if you want local objects to be remotely accessible,
then you do need something much more like capabilities. Given
that mainframes (processor + memory) are so cheap these days,
compared to the cost of a reasonable-size disk, I'm more
inclined to favor putting all potentially sharable objects on
a separate server mainframe and let workstations either cache
them on their local disks or get them over the network whenever
they need to. This requires some architectural changes in the
world to make that network access comparable in speed to, say,
something between a cache miss and a bubble memory access, as
opposed to a disk access.
To the best of my knowledge, Star, like the research machines
(Dolphin and Dorado), has a conventional paged address space;
the Star OS provides for mapping full or partial files into
this space, like Tenex or Multics. The OS happens to be
optimized for mapping sequential runs of pages of a single
file into contiguous virtual pages, but that is an
optimization only.
Subject: Re: Addressing and File Accessing
∂04-Jul-81 1019 gaines at RAND-UNIX Re: Addressing and File Accessing
Date: Friday, 3 Jul 1981 11:04-PDT
From: gaines at RAND-UNIX
To: Chris Ryland <RYLAND at SRI-KL>
Cc: Barns at OFFICE-2, WorkS at MIT-ML
In-reply-to: Your message of 30 Jun 1981 1131-PDT.
It is little known, but the new versions of the Honeywell 6000
have a memory management unit, internally known as NSA (for
New System Architecture, I think), which makes the machine a
form of capabilities machine. It is elaborate and baroque,
but underneath are some very powerful ideas. The architecture
supports multiple independent domains (where a domain is a set
of addressing capabilities), such that a process can consist
of many domains.
Honeywell is slowly attempting to extend the old GCOS-III
operating system to take advantage of this, and the new
version is being called GCOS-8. In addition, Honeywell
some years acquired the XDS Sigma (formerly SDS) business,
together with a little-know, but much loved by its users,
system called CP-5. The group that moved over from Xerox
as part of this deal convinced Honeywell that the operating
system could be ported to the Honeywell processor, and have
produced an interesting system called CP-6, which takes
advantage of the domain features in some nice ways. For
example, a process can have a debugger in one domain to
debug code in other domains, putting it far ahead of
almost any other system I know (including UNIX) in this
area.
Those interested in system design and memory management
approaches ought to be aware of what is going on here. It
represents a significant extension to the thinking about
domains and capabilities. Unfortunately, there is little
in the way of reports or other decent documentation, but
perhaps some beating on Honeywell would produce something.
I'm not sure that this is the right forum for this discussion.
It would be nice if someone would start and manage a conference
dealing with operating system and system design issues. WorkS
and InfoMicro seem to have lots of people interested in these
topics, but they are really focused a bit more narrowly and
differently.
Subject: Xerox 820 Ethernet compatability
∂04-Jul-81 1047 BILLW at SRI-KL Xerox 820 Ethernet compatability
Date: 1 Jul 1981 1402-PDT
Sender: BILLW at SRI-KL
From: BILLW at SRI-KL
To: works at MIT-AI
Message-ID: <[SRI-KL] 1-Jul-81 14:02:56.BILLW>
I have here a piece of Xerox (propaganda) on the 820. I says,
And I quote:
"In addition, the 820 is an investment that will fit into
your long-range plans, since ETHERNET compatibility is
available through the 872/873 Communication Server using
Teletype communications mode on the 820"
I will not make any comments.
Bill Westfield
-----
Subject: EMACS -vs- UNIX
∂04-Jul-81 1219 mike at BRL EMACS -vs- UNIX
Date: 30 Jun 1981 at 2026-EDT
From: mike at BRL
To: WorkS at mit-ml, unix-cpm at udel
cc: Rivanciw.DHQ at udel, benson at utah-20
Folks -
"Eric Benson's message implicitly compares the Emacs
design with UNIX. In his words, Emacs is elegant, UNIX
arcane."
Both this comparison and the conclusion disturb me.
Comparing an editor (which can be thought of as having 3
levels) with an operating system (which has many levels of
complexity) is kind of off-the-wall, but lets play along...
INTENT: The intent of EMACS (as I see it) was to
provide a "what-you-see-is-what-you-get" screen editor
which behaved similarly over a wide range of terminal
keyboards (and terminals), and to permit construction
of Macros to implement higher-level features (LISP
indenting, etc). The intent of UNIX was to provide
a powerful, plesant, and consistent environment for
Computer Science types to experiment and build tools
in.
In a word, the intent of UNIX is "Software Tools",
whereas the intent of EMACS is "Software TOOL". Humm.
USER INTERFACE: Everybody will be quick to agree that
EMACS has a simple to learn user interface, at least to
gain "novice" status. The more intricate commands become
more obscure, and less mnemonic. (Everybody agrees that
Meta-Control-single←character can get obscure).
"What-you-see-is-what-you-get" is Motherhood and Apple Pie
for screen editors, and EMACS definitely succeeds here.
The UNIX user interface is designed to save typing while
remaining reasonably mnemonic. A remarkable number of
"Advanced" users can't type very well, so this is laudable.
Unfortunately, this means users take a while longer getting
used to the command abbreviations. There exist variants of
the UNIX Shell (command interpreter) which accept abbreviated
commands and do other nice, user-helpful things (although the
"standard" (dumb) shells are more common).
Initial EMACS and UNIX users face much the same problem...
LOTS OF SQUINTY LITTLE COMMANDS.
UNDERLYING STRUCTURE: As I understand it, EMACS can
be thought of as having 3 layers: The user interface/screen
control stuff, the Macro level commands, and the macro
implementation level (Typically TECO). Certainly, the top
level is easy to use. The Macro level can usually be learned
and profitably USED by ordinary mortals, but the macro
implementation level (TECO or whatnot) requires a Wizard
to get good results.
UNIX can be thought of as a number of levels, nested:
The terminal driver & line protocol (control/s/q & "cooked" editing).
The Shell (command interpreter)
Programs (System commands & User programs have identical status)
The I/O Library (Buffering & simple file mgmt)
The System-Calls (Direct requests made to the UNIX Kernel)
While each of these levels may have some overlap and
inconsistencies, the general "clean" philosophy of having
only one mechanism to accomplish one result is generally
evident, and a real pleasure! [More on this some other day]
"UNIX productivity must be thought of, not in terms of lines
of code written per unit time, but in terms of lines of code
NOT REQUIRED..."
CONCLUSIONS: I feel that EMACS is one of the better screen
editors around, mostly because of the "macro" facility which
permits powerful features to be built on top, and I feel that
UNIX is definitely the best operating system that has surfaced
to date, because of the consistent system-call interface, and
the "Software Tools" approach to commands.
HENCE, I think that all UNIXs should have an EMACS, and
everybody should run UNIX!
-Mike Muuss
Ballistic Research Laboratory
PS: There exist EMACSs small enough to fit on an 11/34, and
UNIX runs on everything these days, so this is less of
a pipe-dream than it may seem!
-------
Subject: CMU Workstation milestone
∂04-Jul-81 1250 Sam.Harbison at CMU-10A CMU Workstation milestone
Date: 1 July 1981 1509-EDT (Wednesday)
From: Sam.Harbison at CMU-10A
To: works at mit-ai
Message-Id: <01Jul81 150913 SH01@CMU-10A>
I thought people might be interested to know that CMU took
delivery of its 20'th Perq yesterday. Ten are in offices
of people working on Spice-related projects, and ten are
in public areas, also being used mostly for Spice work.
-----
Subject: Re: Ethernet capabilities of 820 and STAR
∂05-Jul-81 0920 guyton at RAND-UNIX Re: Ethernet capabilities of 820 and STAR
Date: Saturday, 4 Jul 1981 18:51-PDT
From: guyton at RAND-UNIX
To: Rivanciw.DHQ at UDEL
cc: Works at MIT-AI
In-reply-to: Your message of 1 Jul 81 11:09:18-EDT (Wed).
I worked for a couple of years for Xerox on the Star product and
after this slanderous message I will no doubt never be welcomed
back. However I can't resist trying to shed a little light on
the confusing state of the Xerox office automation product line.
The key to getting through the Xerox propaganda is to realize that
there is NOT one, but TWO office automation product lines which
have been forcefully "merged." These lines were developed by two
competing groups and don't really have much in common.
The two competing groups are now both under the common banner of
the "Office Products Divison" of Xerox, and are attempting to
cooperate. But until a year or two back . . . well, I'll be
polite and just say that they were very serious competitors.
The older group is out of Dallas, Texas. The new group is split
between Palo Alto and El Segundo (both in California). Here is a
short table summarizing what I think are their main differences:
"SDD" "OPD"
+-------------------------+-------------------------+
Location | California | Texas |
+-------------------------+-------------------------+
Programming | MESA | Assembler |
Environment | | |
+-------------------------+-------------------------+
Processor | Custom Bit-Slice | Standard u-processors |
+-------------------------+-------------------------+
Background | PARC/Research | Electronic Typewriters |
+-------------------------+-------------------------+
Product Lines | Star | 820 |
(Partial list | File Server | 850 |
due to failing | Communication Server| 860 |
memory) | Ethernet | |
| Laser printers | |
+-------------------------+-------------------------+
The two product lines evolved and were designed seperately. When
both groups were merged into the "Office Products Division" it was
decided (wisely I believe) to merge the product lines as much as
possible. So the Dallas products are all going to be on the
Ethernet, and everything will talk with everything else. It is a
worthy goal, but as you might imagine, there are a few rough spots
in trying to do it.
I hear that the Xerox sales force is claiming that they have an
integrated product line for office automation. Low cost 820's up
to the Star. Ah . . . I don't think I can agree with that. I
believe they are undermining their credability when they try to
convince people of this.
As for the confusion arising from the ignorance of the Xerox sales
force . . . they are all out of Dallas and the Star stuff is brand
new to them. When I'm not upset about the propaganda I'm actually
kinda pleased to see that they've done as good a job as they have.
Jim
P.S. Randy -- to answer your specific message, the products in
column one all have the Ethernet designed and built in from the
start. The products in column two have had the Ethernet added
with chewing gum and bailing wire (if at all).
-----
Subject: Switching tasks and context
∂05-Jul-81 0958 JWALKER at BBNA Switching tasks and context
Date: Wednesday, 1 July 1981 11:52-EDT
From: JWALKER at BBNA
To: WorkS at AI
I don't follow the relevance of all this talk about "state
diagrams" in the discussion of resuming a suspended activity.
The human side of resuming something involves answering the
question "Now, where was I?". One very effective answer to
that question is the screen display of the task as it was
when you left it. (It is perhaps not the best answer, but
the best answer involves some meta-knowledge of what you
thought you were doing and your intentions for the various
commands you had used. I am willing to assume that someone
can recognize what they were doing given the set of commands
they had issued before stopping work.)
I concur that the approach taken by the LISP machine and other
multi-window systems (that keep track of various process objects
and reinstate their displays when the objects are selected) is
correct. These systems typically provide two ways of picking up
a dropped ball -- by using a mouse to select one of the objects
whose window is currently visible on the screen, and by using
a mouse to select an object from a menu window that contains a
brief description of each of the objects. The menu gives you
complete context for "where was I?" by showing all of things you
are juggling. This is very important because the fewer details
you have to keep in your head about what you are doing, the more
head is left over for actually getting the work done...
Simply resuming a dropped activity should not be a problem
solving activity ("now, let's see, I think I had that running
as a kept fork under Hermes, which is running as a kept fork
under EMACS..."). The "multi-forking" TOPS-20 execs that exist
at several places (e.g. MIT, Stanford, Rutgers) also support
users who need to move "sideways" to do a task although TOPS-20
doesn't provide anything in the way of reinstating the display
context.
-----
Subject: Multiple Levels of State
∂05-Jul-81 1106 Mike Leavitt <LEAVITT at USC-ISI> Multiple Levels of State
Date: 1 Jul 1981 1815-PDT
Sender: LEAVITT at USC-ISI
From: Mike Leavitt <LEAVITT at USC-ISI>
To: works at AI
Message-ID: <[USC-ISI] 1-Jul-81 18:15:41.LEAVITT>
For general purposes, the LISP approach seems entirely
reasonable. For a workstation, I'm not so sure -- this
is a very special case. There are a relatively limited
number of types of things I am likely to be doing, and
each of them has its own intrinsic priority. When they
are interrupted, they carry with them an implication of
how soon they should be resumed.
For example, if I have to interrupt a phone call and put
somebody on hold, this is basically different from what
happens as I am going through my in-box and someone comes
into my office. Granted, I would like to keep track of
where I was both in the phone call, and in the in-box, but
my system should and could be smart enough to understand
the difference, and indicate that YOU HAVE SOMEONE ON HOLD,
TURKEY, before I finish the interruption and go out for a
cup of coffee. Incidentally, I have been know to leave
people on hold in just such a situation.
Also incidentally, I am not totally crazy about have
a bunch of little icons filling up my screen with
unterminated projects. My desk looks like that right
now, and that is exctly what I hope to get away from.
Mike
-----
Subject: Spatial design for a workstation
∂05-Jul-81 1206 Rivanciw.DHQ at UDel Spatial design for a workstation
Date: 1 Jul 81 10:03:14-EDT (Wed)
From: Rivanciw.DHQ at UDel
To: works at Mit-Ai
cc: Rivanciw.DHQ at UDel
Via: Darcom-HQ; 1 Jul 81 10:49-EDT
I am quite impressed with the degree to which you all responded
to my questions or thoughts on changing modes of operation in a
workstation to better reflect the way one does business.
Here is a scenario I would like to take you through. It is
about Debbie, an action officer in federal agency. Debbie
has an automated office. She has just sat down at her desk
(after getting her coffee) and is about to start her day of
work.
Debbie logs onto the system. Rather than being dropped at
operating system, she is dropped into the office automation
program (or shell). The first thing she sees is the top of
her desk on the screen.
There's an inbox, a notepad, a file cabinet, a phone, a
calendar, etc.
Debbie reaches for the inbox by either moving a cursor to
the inbox or typing "inbox". The inbox expands to fill
the entire display. In the inbox is a stack of messages
- visible on the screen. One of the messages is flashing
(or in a red envelope) indicating some level of importance.
Debbie reaches for that message first by pointing at it
with the cursor (or typing a command to read it).
The message requires a quick response. Debbie must gather
some information from several sources to answer the message.
One source of information is a phone call away. Debbie types
"desk" (or hits a function key labelled desk) and is back at
the top of her desk.
She then points to the phone and the screen fills with a
phone message pad on the left (to take notes on when a
call comes for someone else in the office) and several
phone directories stacked in the right hand corner. She
points to the phone directory labeled "DARCOM". She types
in the first couple of letters of the person's last name
(the person she is trying to reach is me - she does not
know how to spell Ivanciw - so she just types in "IVA".).
The phone directory opens to the first page with names
beginning with IVA. Debbie sees the number and dials it.
While she is talking on the phone she wants to take notes.
She gets back to the top of the desk and points to the
notepad. The notepad expands to fill the screen. She
types her notes on the notepad (which is really just an
editor).
At the conclusion of the phone call the she goes back to
the top of the desk and once again points at the inbox.
The inbox opens with the message she was last reading.
She realizes that she needs the info on the notepad to
answer the message so she types notepad - the screen
splits and the notepad with the phone notes comes on
the screen beside the urgent message.
Ah, yes, Debbie just realized that she needs some info
from the file cabinet. She types "FILE CABINET" or hits
a function key labeled "file cabinet" and a picture of
a file cabinet appears on the screen. She points to
the file drawer labeled "A-C" and it opens revealing 30
folder headers.
But wait, someone has just walked up Debbie's desk and
has asked if she had read the bulletin board this morning.
There was a notice about a presentation in the conference
room sometimes this morning. Debbie quickly hits the "desk
top" botton and points to the Bulletin Board in the corner
of her desk. The Bulletin Board expands and shows subjects
for 15 bulletins. One subject is "PRESENTATION" and Debbie
user points to it and the bulletin expands on the left side
of the screen. Sure enough, the presentation starts in 8
minutes! and Debbie wants to go to it!
Well, now she has to work quickly! Hitting the FILE function
key the screen reappears with the file drawer "A-C" open
showing the 30 folder headers. She quickly spots the file
she wants and using the cursor (or a light pen, or maybe her
finger on a touch sensitive screen) points to the folder.
The folder opens up to reveal 3 separate papers on the topic.
Once again she points to the correct paper and types "close
file". The file closes and she is back in the inbox with the
urgent message, the notepad, and the new file-paper all on
the screen.
Hell! the phone just rang and she is the only one in the
office!! She picks up the phone and finds that it is for
someone else in the office. Quickly she hits the DESK
function key to get to the top of her desk and points to
the phone. The phone expands to show a phone memo pad
and directories. She moves her cursor to the memo pad
and takes a message for her co-worker. She hangs up the
phone and types hits the CONTINUE button. (The phone
message is automatically delivered to the co-worker).
Continue puts her back into the inbox with her three
files.
She decides that she can't finish the message right now
so she hits the bye button and goes to the presentation.
Debbie knows that the next time she enters her inbox the
three files will all be there and she can dig right into
the reply to that message.
********************************
Notice a few things:
o She never had to give a command to run an editor or a
message system. She only pointed to a function and if
it used the message system it used it (INBOX) or if it
used an editor it simply used it (PHONE MEMO, NOTEPAD)
and never required Debbie to type MSG or NED or EMACS
or whatever.
o She was interrupted several times and had to move through
several systems. In all cases she never had to say
"suspend" or "save" - she just went to another function.
When she returned to the function she left it was right
where whe left it. Imagine somebody constantly clearing
off the top of your desk everytime you changed functions
- that is basically what we do in the automated office
tools of today.
The above scenario is a concept that DARCOM is considering
incorporating into its office automation environment.
Please let me know your thoughts on this concept.
Randy Ivanciw
-----
Subject: Ivanciw's ideas &c: comments
∂06-Jul-81 0329 STECKEL at HARV-10 Ivanciw's ideas &c: comments
Date: 5 Jul 1981 (Sunday) 2116-EST
From: STECKEL at HARV-10
To: WorkS at MIT-AI
As an implementor type, I have a few questions. When I work,
I have at least three stacks of things on my desk (where each
stack has sub-sub-sub-, etc. stacks):
a) what I am trying to do on a long term
b) what I started this morning because it's gotta be done today
c) the phone rang and you need it when?!?!
So... the idea of "kept context" is a nice one, but I suspect
that there could be a lot of mess. What happens in Randy's
scenario when the phone call about line 78 (+ or -) required
the use of (1) messages (2) filing cabinet? How do you "file"
where you were in a file cabinet? My file cabinets have about
3000 things in them.
I also have a quibble about the "desk" key. If the interactive
whizzes can make the super page screen work, I would much rather
never have my "desktop" hidden...
I trust my machines about as far as I can throw them when it
comes to saved contexts. Why doesn't the "phone", "pad", etc.
stay around in "icon" form? Part of the idea of piles is that
you can still see the existence of a pile, even if you're not
too sure what's in it.
Unrelated quibble concerning EMACS, &C. I am in the (lonely)
minority of those who cannot stand EMACS, and have limited
tolerance for any screen editor I have yet seen.
A) all I have experienced know far too much about what I
"want" to do (words, lines, etc. are too fully built
in) Quick, what does your screen editor call a "word"?
B) the mouse-type input ones use too many hand motions - I
touch type my TECO commands; why should I have to slow
down?
C) the control-meta-shift ones make me use many fingers at
once. I don't like that either. Also, the more obscure
the character, the less likely it will survive (1) my
memory (2) the system deciding it wants that character
This is merely to say that I think editor design is in the
dark ages, and EMACS ain't God.
Back to Ivanciw's scenario:
Does he envision a page printer, etc., for that item in the
file cabinet? My file cabinets are full of brochures from
manufacturers which arrived by U.S. Snail. Do we encode
them with a TV camera? I have had much difficulty trying to
digest any message longer than about 25 lines via any screen.
The present Workstation message blizzard gets imaged out on
a Calcomp (nee Gould) 200 dot-per-inch plotter in "micro"
form (280-character columns per page) so I can sit down and
quit craning my neck at the screen.)
Anyway, my point is: the workstation seems great if all I/O
is within the electronic environment, but falls down when
you get things like hard paper involved. I hope I provoke
a little controversy.
geoff steckel
Subject: Re: Tools for personal workstations
∂06-Jul-81 0402 Daniel L. Weinreb <dlw at MIT-AI> Re: Tools for personal workstations
Date: 5 July 1981 19:42-EDT
From: Daniel L. Weinreb <dlw at MIT-AI>
To: lwa.INP at MIT-MULTICS
cc: WORKS at MIT-AI
Actually, quite a few users of Multics Emacs (in particular)
do learn to write extensions. Multics Emacs has an extension
language that is particularly easy to learn and start using,
and it is well-documented. Secretaries do this as well as
computer programmers (secretaries are often underrated; there
is a wide range of people doing secretarial things out there,
and some of them are pretty damned smart people). You'd be
surprised.
However, there will always be a lot of users who don't want
to learn to "program". I think the key to making programming
painless is to use programming-by-example systems. Emacs
keyboard macros are a start in this direction, although they
are too simple-minded to do the job adequately at all. Dan
Halbert's Master's degree work at U. C. Berkeley is a
particularly good example of a prototype of such a system.
I hope more people work on this in the future.
Subject: Re: capability machines
∂06-Jul-81 0434 Chris Ryland <RYLAND at SRI-KL> Re: capability machines
Date: 5 Jul 1981 1619-PDT
From: Chris Ryland <RYLAND at SRI-KL>
To: HGBaker.Symbolics at MIT-MULTICS, works at MIT-AI
In-Reply-To: Your message of 3-Jul-81 1415-PDT
Sorry, Henry, but a capability is NOT just a fancy name for a
pointer in a machine that doesn't have enough address space
to begin with. I was referring to capabilities in their full
encapsulation sense, such that you can only manipulate an object
if you have the rights to do so (encoded in the capability)
and you can only do it by invoking an appropriate entry in the
capability's type module. (This is only suggestive; particular
implementations differ, of course.)
No, some capability machines do garbage collection. Hydra did.
Lisp is not a capability machine. Lisp is just a low-level
language for a symbolic-object machine, and thus is attractive
to hackers, because they can grovel with arbitrary "addresses"
when they please (CADDADR, for example.) Of course, no one in
their right mind would use Lisp that way today.
/Chris
-------
Subject: Re: Spatial design for a workstation
∂08-Jul-81 0144 Mike Leavitt <LEAVITT at USC-ISI> Re: Spatial design for a workstation
Date: 7 Jul 1981 1902-PDT
Sender: LEAVITT at USC-ISI
From: Mike Leavitt <LEAVITT at USC-ISI>
To: cfh at CCA-UNIX
Cc: Rivanciw.DHQ at UDEL, works at AI
Message-ID: <[USC-ISI] 7-Jul-81 19:02:46.LEAVITT>
In-Reply-To: Your message of 6 Jul 1981 13:06:26-EDT
If there is a real problem with people preferring to type a few
characters than to scroll a screen (or move a mouse?) then is
one solution a more sensitive touch-screen device than is now
easily available? I guess I would prefer pointing to a
particular icon to any of the above.
Mike
Subject: Contexts as Icons
∂08-Jul-81 0204 Lawrence Butcher at CMU-10A (X335LB50) Contexts as Icons
Date: 7 July 1981 2219-EDT (Tuesday)
From: Lawrence Butcher at CMU-10A (X335LB50)
To: works at mit-ai
CC: Gene Ball at CMU-10A
Message-Id: <07Jul81 221925 LB50@CMU-10A>
"I am sitting at my Personal Computer (terminal) in the middle of
some work and something different comes up. I get confused."
The solutions to this problem range from having lots of windows
on the screen to having little paper airplanes which are shot from
user to user to transmit phone numbers.
The Star lets the user name available services by pointing to Icons.
Pointing to an Icon generates new more detailed Icons, or causes some
Icon-dependent action to happen, or causes a window to appear thru which
the user can interact with the named service. The collection of Icons
and windows are the context within which a user does work.
When a person services an interrupt, he would like to bundle up his
previous context and stick it somewhere. When the interruption is taken
care of, the old context is returned to. It is not reasonable for a
user to have to smash all of his present windows up to the upper left
side of the display to make room to work on his new context. It is equally
unreasonable for a user to have massive piles of overlayed windows.
A much better solution than windows would be a formal context manager
which allows you to group Icons, windows, and related running programs
into little "context" objects. These could be manipulated just like
mail, files, and windows containing command interpreters. One could use
the Context Manager Icon to gain access to and to manipulate lists
of contexts.
In order to be useful these Contexts should be able to contain any
object namable by the user. This should include Icons, instances of
running programs, and should also include the user's organization of
these objects onto his display. A Context should also be able to
include other Contexts.
Users commonly work on a single project for longer than a single
day. To make this possible, Contexts must outlive terminal sessions.
They must be portable between communicating machines. The user should
be able to move down the hall and have his work follow him. The
Context should be available the next morning, even after orderly system
shutdown.
Does anyone have any experience with a system like this??
Subject: Multiple Levels of State
∂08-Jul-81 0219 Vaughan Pratt <CSD.PRATT at SU-SCORE> Multiple Levels of State
Date: 5 Jul 1981 1145-PDT
From: Vaughan Pratt <CSD.PRATT at SU-SCORE>
To: works at MIT-AI
5-Jul-81 11:07:14-PDT,1438;000000000001
Mail-from: ARPANET site MIT-ML rcvd at 5-Jul-81 1106-PDT
Date: 1 Jul 1981 1815-PDT
Sender: LEAVITT at USC-ISI
Also incidentally, I am not totally crazy about have
a bunch of little icons filling up my screen with
unterminated projects. My desk looks like that right
now, and that is exctly what I hope to get away from.
Mike
-----
Automation works yet another miracle. Lotsa luck.
-------
Subject: Re: Switching tasks and context
∂08-Jul-81 0232 Nowicki at PARC-MAXC Re: Switching tasks and context
Date: 6 Jul 1981 10:32 PDT
From: Nowicki at PARC-MAXC
In-reply-to: JWALKER's message of Wednesday, 1 July 1981 11:52-EDT
To: JWALKER at BBNA
cc: WorkS at AI
I can't help describing a Multi-window terminal program I wrote last year at
Stanford (with the help of Vaughan Pratt and Jeff Mogul). My reasoning was
that although "integrated systems" with menus and standard user interfaces were
desired in the long run, we needed a short-term tool to help develop such
systems. My program runs on the SUN workstation, which provides RasterOPs
on an 800x1024 bit screen at roughly the speed of 16 pixels/microsecond, and
computing power about 1/4 of a VAX-11/780.
The program has one simple function: an aribtrary number of virtual terminals
are displayed in arbirary windows on the screen. Each of these virtual terminals
may be to any machine on the local ethernet, or on the Arpanet (via a
gateway). Characters the user types get sent to the "current" host, (except for
one escape character used to enter commands), and characters sent from the
remote hosts get printed in the corresponding virtual terminal. When something
more urgent comes up, you just create another window (which can partially or
fully overlay the other windows), and when you're done you destroy that
window. At any time you may select any window to be "current", so there is no
LIFO restriction.
The important thing is that such a tool WORKS, and I find incredibly useful.
The virtual terminal uses ANSI standard escape sequences, so we can use all the
tools that have been around for a long time (like the SAIL Display Service,
Emacs under TOPS-20 or Unix, etc.) with NO modifications. We are planning to
use this to develop a more integrated system, but it is nice to have the power of
all that useful but obsolete software out there.
-- Bill
Subject: not putting phone messages into electronic mail files
∂08-Jul-81 0247 Paul A. Karger <PAK at MIT-MC> not putting phone messages into electronic mail files
Date: 7 July 1981 18:44-EDT
From: Paul A. Karger <PAK at MIT-MC>
To: WorkS at MIT-AI
cc: PAK at MIT-MC
I must disagree. Putting phone messages for people in the same office
into the computer is extremely useful. My secretary mails mine to me,
so that I can review them either from home that evening or from
another site connected to the network.
This in turn raises a question. If I have an elegant work station at
the office with graphics and icons, etc., how do I read my electronic
mail from home on a cheap, slow terminal (probably 300 baud at best)?
Do I have to learn a whole different command language? Computerese
instead of pointing devices?
Subject: Re: A Quibble or two
∂08-Jul-81 0306 Joe.Newcomer at CMU-10A Re: A Quibble or two
Date: 7 July 1981 1218-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
In-Reply-To: Frank J. Wancho's message of 6 Jul 81 09:37-EST
I see nothing unreasonable about entering something in the computer "for
someone in the same office"; I don't see that spatial proximity should
require using an alternate method of notification, assuming that the
mechanism is already satisfactory. If using little pieces of paper is
more effective than using the computer, this indicates that something
is very wrong in the design of the software. Either the software is
good enough to replace paper, which is presumably the intent, or somebody
blew the design. Thus, we have a very good way of determining if the
designers built a system tailored to human needs, or one which is simply
intended as an ego trip for the designer.
I still don't understand why people seem to think "rings" or "stacks" or
other complex connected graphs are remotely reasonable for representing
past context. The top of my desk has no little strings connecting all the
things I'm doing, and I don't miss them; if I have to deal with such a
mechanism on my computer, then somebody who wrote the software doesn't
understand how people do work. See above predicate test.
A more serious problem is, given massive amounts of state, how do you
preserve them over a system crash? In the case of distributed systems,
it is even harder, since the state may be embodied in many (potentially
unreliable) separate machines. In the best of all possible worlds, when
my personal workstation rolls in the door, I turn it on. If I turn it
off, the result of turning it back on should be to put me back in the state
I was in when I turned it off. Likewise for system crashes. If some server
somewhere crashes, this should be of no interest to me, even if I'm using
it; when it comes back, my work continues just where it left off. None of
this is easy, and some of it is probably impossible, but I think it is
important enough that we should be concerned about reliability at a level
above parity and disk scavengers.
joe
Subject: Re: not putting phone messages into electronic mail files
∂09-Jul-81 0340 JWALKER at BBNA Re: not putting phone messages into electronic mail files
Date: 8 Jul 1981 0939-EDT
Sender: JWALKER at BBNA
From: JWALKER at BBNA
To: WorkS at AI
Message-ID: <[BBNA] 8-Jul-81 09:39:40.JWALKER>
In-Reply-To: Your message of 7 July 1981 18:44-EDT
The answer to "how do I read my electronic mail from home..."?
I have heard PARC aficionados say "Well, you WON'T work at home.
You'll be so much more productive during the day that you can
leave your work behind when you walk out the door." This position
does not constitute an answer to the problem. It is imperative
that we consider all modes of work in designing the next generation
of working environments. More people will start to work at home --
surely we have all heard predictions of electronic piece work and
cottage industry. More people travelling on business will be
carrying tiny terminals with them.
The question is serious. People have to think about how to subset
both the hardware and the software so that the essential style of
the interaction can remain. Of course someone working away from
their normal desk is somewhat handicapped now, but with good
planning (taking the right papers and materials with you) you can
write more on a plane than you can at your desk in the same
elapsed time. Workers whose desks are electronic shouldn't be
prevented in principle from having analogous benefits.
Jan
Subject: Re: not putting phone messages into electronic mail files
∂09-Jul-81 0358 Deutsch at PARC-MAXC Re: not putting phone messages into electronic mail files
Date: 8 Jul 1981 09:39 PDT
From: Deutsch at PARC-MAXC
In-reply-to: PAK's message of 7 July 1981 18:44-EDT
To: Paul A. Karger <PAK at MIT-MC>
cc: WorkS at MIT-AI
I have developed, and hope to publish soon, a detailed proposal
for a protocol between bitmap workstations and mainframes. The
protocol is probably not suitable for a 300 baud connection, but
1200 might be quite reasonable. What it demands on the terminal
end is something of approximately the computing power of the
present home micros -- it needs to be able to do RasterOp, some
simple memory allocation, and sequential communications. It
needs quite a lot of memory for the bitmap(s), but memory is
getting cheaper fast. It is designed for exactly the present
kind of workstation -- bitmap display, keyboard, mouse or
similar pointing device.
Such a protocol is, of course, not sufficient to let you read
your mail elegantly at home. What it requires is a system
(hardware and software) architecture in which the mainframe
is decoupled from the display. Fortunately this is a very
reasonable architecture even for the present generation of
workstations like the Star. If the display component and the
mainframe component are located close together, the bandwidth
between them will not significantly degrade responsiveness
compared to the present more tightly integrated architecture.
Subject: speaking of touch panels...
∂09-Jul-81 0419 Hal at MIT-MC speaking of touch panels...
Date: 8 JUL 1981 0755-EDT
From: Hal at MIT-MC
To: WorkS at MIT-AI
Does anyone know of touch panel technology that is good enough so
that one could use it instead of mice? One would need to be able
to pick out a region the size of a character. I've heard rumors
of systems that allow one to resolve at less than a fingertip's
size, but have never seen one in operation. In general, what do
people think about the use of mice vs. touch panels vs. whatever?
Subject: Re: Spatial design for a workstation
∂09-Jul-81 0427 cfh at CCA-UNIX (Christopher Herot) Re: Spatial design for a workstation
Date: 8 Jul 1981 17:17:53-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: LEAVITT at USC-ISI
Cc: Rivanciw.DHQ at UDEL, works at AI
In response to your message of Tue Jul 7 22:02:18 1981:
The problem with spatial data organizations is that they are
really a class of menus, with the attendant problem that you
can not display every possible choice on the screen at once.
You can deal with this either by enlarging the data surface
(so that the user must move his window over it) or by creating
a hierarchy of spaces.
In either case an expert user will find that it takes more
time to locate a particular command than to type its name.
>From my own brief experience, I think that programmers would
find a spatial layout most useful for organizing short-lived
objects, like contexts. The feature that programmers using
our system like best was the ability to create a number of
such contexts and move among them - like having several
terminals in your office.
Subject: Context Managers
∂09-Jul-81 0446 SHG at MIT-AI Context Managers
Date: 8 JUL 1981 1339-EDT
From: SHG at MIT-AI
To: WorkS at MIT-AI
It was recently suggested (by Lawrence Butcher@cmu10-a) that
in order to manage a "desk" full of icon's what we need is a
global context/icon manager that understands how to organize
the icons on a desk. Several people have suggested that one
needs a hierachical, all-knowing, state preserving "assistant"
in order to provide uniform access, continuity across
interrupted sessions, and conformity across different users
of the same desk.
It probably is my background in workstations (implementing
Smalltalk-80, a very distributed control machine) but
I have viewed the concept of a global organizer and
continuity/conformity enforcer as a mistake.
I see workstation developers and end-users developing zoo
of different types of icons. (The reason I say zoo is that
I see each icon behaving as an anthropomorphic instance of
a real-world tool). Thus secretaries, financial analysts,
accountants, managers and stockbrokers are going to run off
and create icons that behave like rolloindexes, memo-pads,
stock tickers, file cabinets, bookshelves, steno-pads,
calculators, and waste baskets (one can even imagine someone
implementing the anthropomorphic method for hunting through
a waste basket, or even janitors who pick up the trash daily).
Users will create this zoo of icons because they are familiar
with how the real-world devices work, and because the human
race has spent many years perfecting their functions.
I do not see any reason to pre-constrain the system by having
a predefined global conformity rule about an icon's functions
and a global conformity manager who uses that rule to organize
icons.
I have no strong empirical data to back up these opinions, thus
I am quite curious as to what the WorkS community thinks about
this subject.
- Steven Gutfreund
ps: I am assuming a currently implementable workstation. I assume
that the AI community is still far away from an intelligent
assistant that can gracefully learn from a naive user how to
manipulate office equipment and then train temporary workers
on how to use someone's "desk". Since I am not up-to-date on
current research, I could certainly be wrong here.
Subject: Re: Re: Tools for personal workstations
∂09-Jul-81 0509 lwa at mit-csr at mit-multics Re: Re: Tools for personal workstations
Date: 6 Jul 1981 1050-EDT (Monday)
From: lwa at mit-csr at mit-multics
Reply-to: lwa.INP@MIT-Multics
In-reply-to: Your message of 5 July 1981 19:42-EDT
To: dlw at MIT-AI
CC: WorkS at MIT-AI
Interesting. I'd like to see more information on these "programming-by-
example" systems, as I feel that the issue of user extensibility is not
being adequately addressed in present-day designs for office automation
systems.
-Larry Allen
-------
Subject: Re: Contexts as Icons
∂09-Jul-81 0525 obrien at RAND-UNIX Re: Contexts as Icons
Date: Wednesday, 8 Jul 1981 10:34-PDT
To: Lawrence Butcher at CMU-10A (X335LB50)
Cc: works at MIT-AI, Gene Ball at CMU-10A
In-reply-to: Your message of 7 July 1981 2219-EDT (Tuesday).
<07Jul81 221925 LB50@CMU-10A>
From: obrien at RAND-UNIX
I hadn't really thought about this before, but the PLATO
computer-based education system does exactly this - it saves
state between terminal sessions. It does this only for students,
though, not for "authors" (programmers). I hadn't thought of it
before because PLATO is so strange that I really don't think of
it in terms of other computer systems.
State-saving works but can't be done blindly. It turns out
that almost all real applications ("lessons") require the author
to do his own state-saving so that the student doesn't come up
with no context, but is instead presented with a higher-level
frame that tells him where he was and presents some options.
Only blind drill-and-practice stuff can use full state-saving
at all usefully, and sometimes not even then.
Subject: Unfinished tasks, intra-office mail, and system death
∂09-Jul-81 0550 Brian P. Lloyd <LLOYD at MIT-AI> Unfinished tasks, intra-office mail, and system death
Date: 8 July 1981 07:19-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: WORKS at MIT-AI
An interesting point was made about the necessity of being able to
conveniently hand-off a task to another person. Certainly it would
be simple to just dump the task's parameters from RAM to disk and
restore them again elsewhere. While technically feasable (I have
done that on my CT system to provide task interruption capability),
this is tantamount to scooping up the mess on your desk and dumping
it on someone else's. In any case the user is probably going to
reorganize it somewhat in order to make a smooth transition. Given
this, I don't think that special capabilities need to be created
to meet this "need" (I know that those of you using large central
machines may have dificulty with my technique depending on system
architechture).
As far as intra-office mail for phone messages is concerned, I am all
for it. I dislike being told that "there has been a phone message
waiting at the operators desk for you for several hours. Why don't
you ever pick up your messages ..." especially since I have been
waiting for the call and I happened to be away from my desk for two
minutes when it came. Paper doesn't hack it here.
There are some tasks that are very painful if you lose your work
because of system death and others that are unimportant. If I
have been editing a document for hours and I lose it all because
of a system crash, I am going to be VERY annoyed. On the other
hand, if I am reading my mail and the system goes down, it will
not be very painful for me to recover from that situation. We
are going to have to do serious study as to which tasks can be
recovered easily.
Convergent has come up with what I believe is a unique method of
protecting a user from a crash during an editing session. All
user keystrokes and the original document are maintained through
an editing session. If the system dies or I wish to go back in
time in my editing session, I can do a replay and watch the system
duplicate my editing session in short order. This is an interesting
approach and I have found it to be VERY useful (like the time someone
pulled my plug when I was four hours into an editing session ... ).
Brian
Subject: Re: A Quibble or two
∂09-Jul-81 0616 Deutsch at PARC-MAXC Re: A Quibble or two
Date: 8 Jul 1981 09:44 PDT
From: Deutsch at PARC-MAXC
In-reply-to: Joe.Newcomer's message of 7 July 1981 1218-EDT (Tuesday)
To: Joe.Newcomer at CMU-10A
cc: works at mit-ai
Reliable preservation of large amounts of state in the face of
hardware failures is a topic which has been explored extensively
in the data base world. (This is a nice example to support my
contention that the present tendency of computer science to fragment
into subspecialties is to be deplored.) Generally speaking, the way
to overcome the problem is ALWAYS redundancy. The forms of redundancy
that we have explored the most are (1) thinking of the workstation as
a cache for "truth" embodied on a remote file server, or (2) logging
important state changes on a server so that the workstation state can
be reconstructed (possibly slowly) if a crash occurs. A more exotic
architecture involving multiple copies and voting is explored in a
soon-to-appear thesis by Dave Gifford (MIT). The bottom line is that
the technology is available, if manufacturers and software houses
choose to offer it.
Subject: Reliability
∂09-Jul-81 0643 Joe.Newcomer at CMU-10A Reliability
Date: 8 July 1981 1348-EDT (Wednesday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
In-Reply-To: Deutsch@PARC-MAXC's message of 8 Jul 81 11:44-EST
I have contended for several years that I don't need better languages,
compilers, or editors NEARLY as much as I need a database management
system. Alas, the conventional DBMS is oriented to social security
records. I once mentioned "well, you put all that on a database"
to someone and they immediately began to explain how they had
variable-length text which a database system "couldn't handle".
Of course, a large class of uninteresting systems think in terms of
fixed-length records, but what we lose by ignoring them is that they
solve a whole lot of other problems. I once worked in the "real
world" on a banking system, and it is a good way to learn to be
paranoid about hardware and software. When you start playing with
millions of dollars of real bucks, and find that people audit their
checking accounts (and even interest on savings) to the nearest penny,
AND your company has posted a mongo amount of dollars in bond to back
up their promise that they WON'T screw up, you find that redundancy is
a way of life. DBMS systems have all had to deal with this class of
problems; the fact that their image of the data is prehistoric does
not invalidate the other solutions.
From a personal workstation viewpoint, the problem is to implement
the redundancy of state at a very low cost. If my machine crashes,
I want to boot it and get the display looking just like it did
before the crash, having lost perhaps a few small edits, or the
mail message I was composing (if it was shorter than some low
threshold) or possibly the window I just the instant before had
brought up. Doing this cheaply requires ingenuity.
joe
Subject: Re: JWalker comments on working at home, on planes, etc.
∂13-Jul-81 0920 Zellich at OFFICE-3 (Rich Zellich) Re: JWalker comments on working at home, on planes, etc.
Date: 9 Jul 1981 1036-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
To: WorkS at MIT-AI
Some of us already *do* work at home, and the receipt of stuff
that shows up in my office inbasket is a problem -- I have to
go in and get it periodically, or else have it batch-mailed to
me (the Post Awful actually does pretty good work here - I get
everything the next day).
At home I have a pretty nice workstation, but on a recent
vacation trip I took a TI745 with me, and found it not nearly
as useful as it had been when it was my *only* terminal. My
work methodology has changed so much due to the availability
of the workstation that it has become almost impossible to
get my work done with a terminal with lesser capabilities.
My electronic "filing cabinets", etc., are optimally organized
for a windowed display, and have become extremely difficult to
use from a TTY or simple scope.
It so happens that my workstation is relatively dumb (using
its internal microprocessor to handle NVT requirements only),
but the next generation should be quite intelligent - maybe
being my prime "host" itself. This all points up two problems
very neatly:
1. I need a portable workstation (or portable terminal that
can access my workstation);
2. If I use a portable terminal, then I need access to my
home workstation (the future one, that will be a
standalone system). This future system must be capable
of two-way communication; it can *not* be used strictly
to dial out to other hosts. It has to be a full host
in that it must be accessible from a remote user, and
probably from remote hosts and other workstations as
well. (gee, sounds like I just read RFC 782)
-Rich
-------
Subject: Working at home
∂13-Jul-81 0920 Joe.Newcomer at CMU-10A Working at home
Date: 9 July 1981 1447-EDT (Thursday)
From: Joe.Newcomer at CMU-10A
To: JWALKER at BBNA
CC: works at mit-ai
In-Reply-To: <[BBNA] 8-Jul-81 09:39:40.JWALKER>
Huh? "I'll leave my work behind when I go out the door?"
I've never heard such bullshit. First of all, it makes
the rather bizarre assumption that I even want to come IN
the door. Actually, I would much rather work at home. This
means such serious issues as how to get reasonable communication
bandwidth between my processor and the rest of its network is a
very serious problem. And it also seems to be predicated on the
strange (and patently false, in my case) assumption that one WANTS
to leave the machine behind. I ENJOY what I'm doing, and want to
be able to do it equally well from home or "work". Thus the goal,
for example, of giving every CMU researcher a personal machine is
not really satisfactory; I need two, or at least a display with a
high-bandwidth (say, 10MHz) connection to the "real" machine.
Perhaps in that strange world where people turn their minds off
when they leave the office this is a reasonable attitude, but I've
never yet met a professional in any area who was capable of doing
this. And if you DON'T make the facilities available at home, you
are defeating the purpose of having personal workstations: to make
individuals more productive. I don't think it is the domain of
office automation designers to dictate when and where one has
automation available. Assume it needs to be available 24 hours
a day, 7 days a week, at home and "at work", THEN figure out what
the problems are.
I have this from direct experience. When I had a 1200 baud
C-100 in the office and a 1200 baud C100 at home, I could work
interchangeably in either location. When I got 9600 baud in
the office, I worked less at home. Now that I have a Perq in
the office, I can't work at home at all. This is a real drag.
I see absolutely no philosophical reason to not provide equal
computing facilities at home and at work. The only limitations
are technical (like bandwidth) and financial (most companies
can't afford two $30K workstations per user). So "office"
automation designers should go after those problems, and quit
making such totally wedged statements that seem to reflect a
basic misunderstanding of what a "personal workstation" really
should be!
joe
Subject: Office of Tomorrow, where is it?
∂13-Jul-81 0921 DREIFU at WHARTON-10 (Henry Dreifus) Office of Tomorrow, where is it?
Date: 12 Jul 1981 (Sunday) 1955-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: works at MIT-ML
Workstations of Tomorrow, the office of tomorrow. [Part-I]
A general feeling by most consultants, including myself, is that
the office of the future will be distributed geographically. Not
only will the 'traveling' type person be a long-distance link, but
projects will be connected by different branches - communicating
electronically.
As this effects the workstation, indeed a traveling companion
will be developed. Something akin to the Xerox "NoteTaker".
Working from home will also be a common and practical extension.
Workstation hardware will have to provide the geographic service
at some point in the not too distant future.
Somewhat more extensive from Telex/TWX 'Datagram' service, an
electronic 'Terminal in the Hotel' will at some point be provided.
I don't see any major technological problems in that. Most people
I have spoken to say they would pay $ 25.00 or even $ 50.00 more
a night to have a computer screen and a dial up modem at their
disposal.
Flying on an airplane? Why not? First Class, Business Class,
Electronics Class and Coach. Electronics class, with SONY(tm)
TypeCorders, floppy disks, and even telephone capabilities for
burst communications to one's favorite computer. It beats the
lousy movies they are showing these days.
Henry Dreifus
[Subj: Bravo/Hypertext]
∂12-Jul-81 1803 John Howard Palevich <TANG at MIT-AI>
Date: 9 July 1981 09:02-EDT
From: John Howard Palevich <TANG at MIT-AI>
To: WORKS at MIT-AI
The Bravo (& BravoX) secretary-type editors on the PARC
Altos have the "save every keystroke and the original file so
that we can always reconstruct" hack. When the system starts
to reconstruct it puts a cute "Your Editor is Experiencing
Temporary Difficulties, Please Standy By" message on the
screen, much in the style of the message TV stations read
out over the air after they drop the camera on the floor.
What ever happened to Ted(tm) Nelson's Hypertext system,
where the entire state of the document (down to the time between
keystrokes of the person editing in) was saved, and the viewer
of the document had the option of expanding the footnotes into
the referenced texts, and all that sort of thing? I think that
he was even addressing the problems of copyright & royalty
payments. . . perhaps I should mail this to human-nets, instead.
Subject: Workstation Reliability and Redundancy
∂12-Jul-81 1724 rmc at CCA-UNIX (Mark Chilenskas) Workstation Reliability and Redundancy
Date: 9 Jul 1981 14:23:18-EDT
From: rmc at CCA-UNIX (Mark Chilenskas)
To: WorkS at mit-ai
It sounds as if your problem is similiar to (and can use)
distributed database technology. The icons can be viewed as
tuples in a relation (of work to be performed, status of work,
worker, what have you). Some icons would be provided by the
system in a common format, others would be customized by each
user, probably using some menu driven options package although
for "sophisticated" users I suppose full programming might be in-
volved. The basic idea would be to have all nameable items
stored away on disk with their requisite status information.
This would preserve state info over crashes of the individual
workstations, but does not solve the problem of going to a new
workstation if your desk dies for a day or two.
In a distributed data base it has long been theorized that redun-
dant data will provide better reliability over crashes, machine
outages, etc. and provide some (possibly limited) data to the
user even if their home system is currently unavailable. Of
course this is a pain, because you have to work up protocols to
insure that the data items all stay consistent with each other
and use up lots of overhead timestamping messages or locking and
unlocking at foreign sites to update data and it is still all
very, very SLOW! The fact that Ethernet has a higher data
transmission rate than the ARPAnet and that the updates may have
simple enough formats to use coding schemes will help. But i
suspect that this will still eat an unacceptable amount of com-
pute power at task initialization and termination. Update trans-
actions are where redundancy hurts most.
Distributed databases are only partly understood. One problem is
in deciding how to split up the data. An obvious technique would
be to store templates for all common icons at each
workstation/site and let each user pick which other sites he is
likely to use occasionally. Unfortunately this will mostly mean
the user will be too brash (i don't need backup) or too cautious
(store it everywhere! Why do i run 10X slower than everyone
else?). And what do you do when the database crashes? What info
is right, and what is out of date (especially if a locking rather
than timestamp protocol is used)? This is not to mention network
partitions...
It still seems like a good application of the technology. The
redundant data goes a long way toward assuring you the type of
reliability you want. Using a common database would allow one
mechanism for transfering tasks/icons from one desk to another.
The networks will be reasonably fast. Workstations are getting
more compute power. And slowly we begin to understand some of
the design and recovery problems. There is some NICE research to
be done here...
R Mark Chilenskas
Subject: Automated desk
∂12-Jul-81 1803 wilson at CCA-UNIX (Gerald Wilson) Automated desk
Date: 9 Jul 1981 12:38:27-EDT
From: wilson at CCA-UNIX (Gerald Wilson)
To: csvax.works at Berkeley
The problem of keeping track of what quickly becomes a
multidimensional space is one we faced in the extensions of
Negroponte's work in our SDMS and VIEW systems. For SDMS we
approached it by providing two kinds of "world maps". The first
is simply a synopsis of the contents of the current work space.
Thus if you are doing several related things in this single space
(eg. building different portions of a large program), you can
always find from the world view (shown on a separate screen at
all times) where the other portions reside. The second type of
world map is a side view of all of the work spaces arranged into
a tree ( or network ). This shows a box with a label for each
work space, lines showing the connections between work spaces,
and a highlight for the work space where you currently reside.
The user can switch between world maps at the push of a function
button.
This is only a partial solution to the problem, as it does not
capture any of the real semantics of the situation. For example
you do not know how you got to the current work space, or any of
the contextual information associated with the current instance
of the work space. These are issues that we are currently
addressing in VIEW, but I have no fabulous insights to report
yet.
Subject: Re: Context Managers
∂12-Jul-81 1803 Joe.Newcomer at CMU-10A Re: Context Managers
Date: 9 July 1981 1501-EDT (Thursday)
From: Joe.Newcomer at CMU-10A
To: SHG at MIT-AI
CC: works at mit-ai
In-Reply-To: SHG@MIT-AI's message of 8 Jul 81 12:39-EST
I guess I never thought of the icons as being pictures or
illustrations, but just names of windows (perhaps visible
corners of windows). Thus having a global manager in a
workstation that keeps track of all the windows seems
natural. What is your reaction to this simpler model?
joe
Subject: Icons
∂12-Jul-81 1804 Brian P. Lloyd <LLOYD at MIT-AI> Icons
Date: 9 July 1981 08:31-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: WORKS at MIT-AI
Currently we catagorize workstation functions on the basis of
the existing tools we now use. Is it not possible for us to
define a new set of functions that encompasses the current
range of tools/procedures, but is much smaller? Given this,
we will have to develop a new set of icons to define the new
functions. If indeed we must define new icons, don't we lose
the existing mental correlation between picture and function?
Perhaps we should look at the whole problem from another angle.
Let us assume that the "intelligent desk" leads us in the
direction of modified worker activity. I think we should do
another system analysis and see if we can come up with a new
view of the problem: one that has an elegant [simple] solution.
Brian
Subject: Re: Reliability
∂12-Jul-81 1724 Joe.Newcomer at CMU-10A Re: Reliability
Date: 9 July 1981 1831-EDT (Thursday)
From: Joe.Newcomer at CMU-10A
To: kolling at PARC-MAXC, works at mit-ai
In-Reply-To: kolling@PARC-MAXC's message of 9 Jul 81 16:21-EST
Assume the following:
A series of transactions is required to generate a consistent
database.
The cost of repeating a transaction is outrageously high.
The cost of restarting a series is even higher.
The cost of saving state at the client so that the series may
be continued is negligible.
What is the cost of the mechanism that guarantees that enough
state is preserved at the server to continue the series of
transactions given that either the server or the client may
crash?
Assume that the client, when resuming the series, may elect
to "continue" or "abort". Assume that "abort" is a truly
rare occurrence.
This is my image of the requirements of, say, a crashproof
editor that will lose no more than one keystroke if either the
client or server crashes. Note that although the "database"
(file being edited) is in an inconsistent state (relative to the
desired state), the user wishes to resume editing at the nth or
n-1st keystroke. Thus, viewing the user as the "client" and the
editor as the "server", the cost to the user of remembering which
keystroke came last or will come next is negligible. As we move
further back in time, the cost of restarting the series becomes
higher and higher. Assume for values of time > 10 keystrokes
the cost is nearly infinite. As far as I can tell, transactions
do not allow state to be SUSPENDED; they only guarantee that
under one definition of consistency, the state will always be
consistent. For a workstation, the two states in question are
the state of the workstation and the state of the work. Any
time the workstation state is consistent, the state may be
saved (the transaction completed), but this has nothing to
do with the state of the work. I think we are a long way
from being able to deal with the latter, since I think it
is perfectly reasonable to shut down the system or take a
crash when the "work" is inconsistent, as long as we can
return to the same state of inconsistency upon return and
allow the work to proceed.
joe
Subject: Touchpanels
∂14-Jul-81 0934 Steve Saunders <SAUNDERS at USC-ISIB> Touchpanels
Date: 13 Jul 1981 0939-PDT
From: Steve Saunders <SAUNDERS at USC-ISIB>
To: WorkS at MIT-AI
Why do all the answers in the digested replies on touchpanels share
these glaring misconceptions?
- that a touchpanel must be mounted in front of the display;
- that a touchpanel's resolution is limited to fingertip size.
1. Any of several touchpanel technologies, including the Elographics
and Sierracin commercial units, is entirely suitable for use away
from the display surface -- say, just where you would put a
"tablet" (pen-on-a-wire type), but without ever having to find &
pick up a pen or even find the mouse where you left it. The desk
area used need not be larger than a mouse-field.
2. This same touchpanel technology, at least, offers resolution that
is much much finer than the size of the touching fingertip -- I
have personally built and used some, and with cursor feedback I
can select individual pixel positions *within* the (projected)
area of my contact "fingerprint". This is done simply and
naturally (noone has to be coached) by rolling the fingertip.
The resistive material reads out the centroid (in some sense)
of the contact patch, allowing very sensitive control for fine
positioning, as well as instantaneous pointing without having
to find the pointer (pen or mouse) first.
*Of course* there is a tracking cursor on the display, just like a
mouse/tablet. To assume absence of this well-understood software
device gives extremely unfair comparisons.
Now that we all have that straight, how about some reconsidered
answers? Preferably this time from users of real touchpanels,
not those low-resolution or screen-mounted special-purpose
devices that were blasted (rightly) in the recent batch of
replies.
Steve
Subject: Re: Touchpanels
∂15-Jul-81 0429 JWALKER at BBNA Re: Touchpanels
Date: 14 Jul 1981 0926-EDT
Sender: JWALKER at BBNA
From: JWALKER at BBNA
To: SAUNDERS at USC-ISIB
Cc: WorkS at AI
Message-ID: <[BBNA]14-Jul-81 09:26:52.JWALKER>
In-Reply-To: Your message of 13 Jul 1981 0939-PDT
You might have noticed that some of the touch panel notes pointed
out the semantic poverty of a touch when compared to the multiple
selection buttons on a mouse. That difference holds wherever the
touch panel is mounted. It means that touch panel driven systems
have to use more menus than are needed with a mouse driven
interface.
Jan
∂15-Jul-81 0444 Steve Saunders <SAUNDERS at USC-ISIB> Touchpanel prejudice
Date: 14 Jul 1981 0839-PDT
From: Steve Saunders <SAUNDERS at USC-ISIB>
Subject: Touchpanel prejudice
To: JWALKER at BBNA
cc: Saunders at USC-ISIB, WorkS at MIT-AI
Again, random assumptions are being made. Who says you can't
mount buttons where they can be used easily with a touchpanel?
Specifically, you can take advantage of the normal use --
pointing with one hand while the other remains in "home position"
at the keyboard -- to provide either mouse or touchpanel with
lots of "buttons" (just 'cause they have letters printed on top
doesn't mean they aren't buttons!). Of course, the kinesthetics
aren't exactly alike; but the assertion implied by JWalker that
mouse is necessarily better on this ground is pure assumption.
If there's evidence, tell us about it!
I didn't say there was no DIFFERENCE, just that the touchpanel's
inferiority as being asserted on unfair (scientifically careless)
grounds, that touchpanels were being castigated for faults they
don't in fact have. They are indeed different, and the good and
bad points of that difference need to be carefully explored
without the interference of preconceived conclusions.
Steve
-------
∂15-Jul-81 0458 Joe.Newcomer at CMU-10A Re: Touchpanels
Date: 14 July 1981 1253-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: Steve Saunders <SAUNDERS at USC-ISIB>
Subject: Re: Touchpanels
CC: works at mit-ai
In-Reply-To: Steve Saunders's message of 13 Jul 81 11:39-EST
Steve,
I was assuming by touchpanels that people mean those transparent
devices, or LED-matrix arrays, that get mounted on terminal
screens. I therefore don't see any distinction between the Bit
Pad One with a piece of hardware for the cursor and the Three
Rivers touch-tablet which requires only my fingertip (except I
don't have four buttons on the touch-tablet). The fine point
that touch tablets need not be mounted on the screen did not
escape me...in fact, I even cite the 3RCC touch tablet in an
earlier note.
joe
∂15-Jul-81 0515 Steve Saunders <SAUNDERS at USC-ISIB> Touchpanels vs Tablets
Date: 14 Jul 1981 1014-PDT
From: Steve Saunders <SAUNDERS at USC-ISIB>
Subject: Touchpanels vs Tablets
To: Joe.Newcomer at CMU-10A
cc: WorkS at MIT-AI
In-Reply-To: Your message of 14-Jul-81 0953-PDT
Joe,
There is one real distinction between BitPad et al. and
sensitive-surface touchpanels, and that is the need or absence of
a gadget (pen, e.g.) that one must find and pick up (or take a
hand position on) before pointing/drawing. Is it your experience
that this is not important? I get *terribly* annoyed by the pen
on our Perq (which came with a Summagraphics tablet, not the
transparent touchpanel -- I don't know why). I think that a pen
on a cord is much worse than a mouse; what I don't know is whether
finding a mouse every time is worth having those buttons there
rather than (say) near the left hand. Have you experimented
with fully-worked-out setups that use each of the competing
technologies to its own best advantage? I really would like
to hear some information on this.
Steve
∂15-Jul-81 0533 Joe.Newcomer at CMU-10A Re: Collected commentary on touchpanels
Date: 14 July 1981 1235-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
Subject: Re: Collected commentary on touchpanels
In-Reply-To: "The Moderator"'s message of 13 Jul 81 07:30-EST
What's wrong with light pens? The same thing that is wrong
with the standard pen that comes with the Summagraphics Bit Pad
One: you've got to pick the damn thing up! I went nearly crazy
trying to use an editor for two weeks with my Bit Pad, because
the editor ONLY accepted cursor motion thru the tablet and the
ONLY device I had for pointing was the pen! One of the worst-
designed systems I ever used. After two weeks, the 4-button
mouse came in, and most of the headaches went away, but I still
had to keep taking my hands off the keyboard for the smallest
cursor motions. Now we have an EMACS like editor that accepts
cursor movement and positioning commands from the keyboard or
tablet, and it is really nice; small relative motions can be
done quickly from the keyboard and large dragging motions can
be done with the tablet; I find the system quite friendly.
(As an aside, pens seem to be predicated on the idea that holding
a writing implement is a "natural" action and comfortable. I've
never found holding a pen comfortable, and have always preferred
to type rather than write. I write almost nothing; if it is
worth commiting to an medium outside my brain, I type it into
the computer!)
joe
∂15-Jul-81 0551 Marshall Presser <MPresser at MIT-Multics> touch panels
Date: 14 July 1981 1331-edt
From: Marshall Presser <MPresser at MIT-Multics>
Subject: touch panels
To: WorkS @ MIT-AI
The touch panels I have seen had very fine precision, but very
high variability. As a reult, the software running the terminal
had to know what was being displayed where, so as to interpret
seemingly misplaced results. We tried cross wires held together
by rubber bands on the first model, but this gave us only the
roughly 20 by 20 points on a standard sized monitor. It is
unclear whether many people can or care to manipulate in a n
area smaller than a fingertip.
Others tried special resistive and capacitance sensitive
material, but this proved too variable. They, whoever they
are, tried invisable conductors inside channels on a plastic
overlay on the monitor, but this technology proved expensive
and the stuff wore down after a while.
What did prove successful was a two monitor system, one for
display purposes, and another as the "input" device. There
was of course, the problem that the programmers could not
eat peanut butter and jelly sandwiches while working late,
for it marred the surface badly. An image of a keyboard was
generated, but the touch was so awful, that a small keyboard
of the regular variety was hung on when large amounts of text
input were required. One application had people selecting
theater tickets by push down on the monitor over a picture
of seating plan of the theater or stadium. The main appli-
cations for such a terminal were commerical, for highly
reprogrammable banking terminals, and for computer access
to naive users about community information. In the second
case, they were to be used at public libraries, community
centers, etc.
∂15-Jul-81 0607 Joe.Newcomer at CMU-10A Re: joysticks
Date: 14 July 1981 1249-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: Gary Feldman at CMU-10A
Subject: Re: joysticks
CC: works at mit-ai
In-Reply-To: <13Jul81 205424 GF20@CMU-10A>
The reason joysticks are losers deals with the interaction
between the hand motion and the screen cursor motion. In
fact, it takes a lot of skill to convert a desired motion
on the screen to an appropriate nudge of the joystick. Thus,
joysticks usually result in a lot of "hunting" as the cursor
constantly overshoots the target and the user applies smaller
and smaller corrections to get it to land on the desired point
on the screen. See Stu Card's thesis; I know he presented the
reasons at his oral (I was there) and assume they are also in
his thesis.
I have no experience with tracking balls, and am currently
reluctant to offer opinions on them since I THINK I know a
very, very cute way to implement one...and I won't say more
until I've sold the idea.
joe
Subject: Picture vs. Window names
∂15-Jul-81 0633 wilson at CCA-UNIX (Gerald Wilson) Picture vs. Window names
Date: 13 Jul 1981 13:50:10-EDT
From: wilson at CCA-UNIX (Gerald Wilson)
To: works at MIT-AI
I think that the importance of worrying about the content of the
windows is closely tied to the nature of the working environment.
If the user is working with a relatively small number of windows
all of which have a fairly short half-life (probably no more than
a day), then having a nice window manager which just keeps track
by name is probably adequate, and certainly much better than
typical current facilities. I equate this solution to the ability
to declare multiple full-screen windows in EMACS, and then ask
about what windows you have created. This works nicely for me as
long as I chose good names for the windows, and I don't 'drift' on
to new things without closing out old windows.
The problem that is of primary concern to me is the environment
where a user has lots (probably hundreds over the course of a
year) of windows, many of which have long lives (> month), and
which are in various states of activity at any given moment.
When I handle this manually I often end up with a hierarchy of
storage and state preserving methods, with the "manager" being
a combination of paper and electronic messages and a mental
index. I find all the same problems that have been discussed
or alluded to in "works" messages:
* Windows change in priority and/or importance based on both
my own actions and actions of others. The biggest problem
seems to be that the actions of others can cause me to make
dramatic changes in my window organization, at least for a
short time.
* I can handle a handful of windows with little problem for a
moderate time. When the number grows I begin to lose track
of some. When the time period of a low priority window's
life is long, I also begin to lose track of it. This
corresponds to the usual observations about human memory.
* Almost invariably there are multiple relationships between
windows, and thus multiple organizations of the windows. A
single window name rarely means anything to more than one
of these views of my world. The key retrieval method is my
mental association between the window name and the semantic
aspects of the window that are of interest under given
circumstances.
* The window relationships depend upon not only the window
semantics, but also project priorities, personal preferences,
interests of the moment, machine availability, dependencies
upon co-workers, etc. Much of this meta-information about
the window organization is important to keep available, and
is used in developing priorities and schedules.
* When new windows are created I must thread them into the
existing structures, and also determine if any new structures
are required. The deletion of old windows may affect windows
not directly linked to the deleted window, as the reason for
the deletion may have implications for other windows not
otherwise related.
My conclusion is that if we are to use computers to maintain much
of our current paper files, we must provide windowing facilities
that are more versatile, more semantically oriented, and more
easily interconnected than the window naming and other similar
approaches would allow. I think that the use pictures, color,
shape, abstractions, sound, etc. are essential to this process.
They sure seem to help in manual systems, and I have not found
effective substitutes for many of them in my own limited work.
When talking with graphics people, they always use "icon" to mean
the 'total symbol', not just as the name of a region of the screen.
Although this does not imply that icon refers to any semantics, I
guess I have felt that this is a natural extension of the grahics
term.
[Subj: more on icons]
∂15-Jul-81 0700 ihnss!mhtsa!harpo!chico!esquire!nrh at Berkeley
Date: 13 Jul 1981 20:54:16-PDT
From: ihnss!mhtsa!harpo!chico!esquire!nrh at Berkeley
To: WorkS at MIT-AI
Phooey! This "endless hierarchy" of deletes is just plain silly!
Given delete and EXPUNGE, what if someone wants a file that has
been EXPUNGED? Should there be a little "Hardy Boys" icon which
given the burned junk from an "expunged wastebasket" icon could
re-construct (perhaps only in part) what was on the burnt paper
(the expunged file)?
And how about a little "paper shredder" icon so you could prevent
the retrieval of an EXPUNGED file? And if you didn't want to
trust your users to do that, you could always have a "bogus paper
shredder" icon which doesn't really shred things, but merely drops
them in the wastebasket.
On the other hand, with regular backups, and an "archives" icon,
perhaps you could simply trust your users most of the time, and
recover from backup when that failed (perhaps a "god from the
machine" icon could be shown disgorging the "lost" files).
Subject: Re: Unfinished tasks, intra-office mail, and system death
∂15-Jul-81 0714 Ted Markowitz <TJM at MIT-XX> Re: Unfinished tasks, intra-office mail, and system death
Date: 14 Jul 1981 1700-EDT
From: Ted Markowitz <TJM at MIT-XX>
To: LLOYD at MIT-AI, WORKS at MIT-AI
In-Reply-To: Your message of 8-Jul-81 0719-EDT
Perhaps with the price of harware dropping at the rate it has
been, the TANDEM approach (duplicate processors, disk subsystems
which "mirror" the data, etc.) might be a reasonable method to
accomplish state saving. I don't see this right away, but it
does provide another avenue to make sure that your desk doesn't
wind up 'disappearing' because of an electrical spike or a loose
cable.
--ted
Subject: Reliablity
∂15-Jul-81 0729 BHYDE at BBNG Reliablity
Date: 13 Jul 1981 1120-EDT
From: BHYDE at BBNG
Sender: BHYDE at BBNG
To: Works at MIT-AI
Message-ID: <[BBNG]13-Jul-81 11:20:13.BHYDE>
Folks,
There are very few new ideas that computing has had to date.
The keystroke backup file is only the editor instantiation of
a very old idea; double entry bookkeeping. An idea that some
have blamed all capitalism on. As each transaction occurs in
any organization it is recorded in two places, the journal and
the account book that it is related to. These two sets of books
are stored in separate places if at all possible and either set
can be used to reconstruct the other. This is a very important
reliability mechanism since it is the only one that is acceptable
to accounting organizations. As the only "certified" mechanism
it is the only primitive available for most commercial systems
to achieve reliability. Thus the terms audit trail or journaling
are very popular in commercial product offerings.
Ben Hyde.
Subject: SUN Workstation
∂15-Jul-81 0747 Andy Bechtolsheim <AVB at SU-AI> SUN Workstation
Date: 13 Jul 1981 1738-PDT
From: Andy Bechtolsheim <AVB at SU-AI>
To: WorkS at MIT-AI
From: Minsky at MIT-AI
Subject: SUN query
Gee, where does one get a SUN and how much does it cost?
--------------------------------------------------------
SUN Workstation Synopsis:
Processor: 8 MHz 68000, executing without wait states.
Memory Management: two-level, multi-process, segment-page memory map.
Main Memory: 384 kBytes (128 kBytes reserved for frame buffer).
Graphics: 1024 by 800 pixel display, high-speed "RasterOP".
Network: 3 MBit/sec "experimental" Ethernet.
Pointing Device: optical "mouse".
Backplane Bus: Intel Multibus.
Operating System: Microsoft Xenix.
OEM-Price: under $10,000.
We are currently evaluating manufacturing arrangements for
SUN workstations. Stanford University plans to get 25 SUN
workstations by the end of this year. If you are interested
in participating in this pilot production run, please contact
AVB @ SAIL.
Subject: Collected Responses on Touchpanels II
∂16-Jul-81 0524 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected Responses on Touchpanels II
Date: 16 July 1981 0700-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
Here is the second set of collected responses on touchpanels
and other cursor moving devices. They are being distributed
in this form rather than as individual messages, because this
is the only way that we can manage to promptly distribute the
incoming volume of mail to this list.
Enjoy,
RDD
------------------------------
Date: 15 July 1981 08:54-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
Subject: BitPad Experiences
To: WORKS at MIT-AI
We at DEC did not have mouse hardware on hand. What we did
have was a SummaGraphics BitPad with crosshair cursor that has
4 buttons (bugs in the PARC terminology) on top. It was fairly
easy to write software so that we could have a relative postion
mouse instead of an absolute location cursor. We even hyped
up the sensitivity of the mouse so that simple (wrist only)
movements could carry one across the entire screen. One can
even lift up the cursor and replace it like a real mouse.
Opinions:
Given the way the smalltalk window editors work, I can keep
almost all of my activity off the keyboard. Indeed I think
if I was given a chord keyboard in my other hand (5 buttons
could give me 120 different keys) then I could completely
get rid of that anachronism of the industrial age: the 4
row QWERTY keyboard.
- Steven Gutfreund
------------------------------
Date: 15 Jul 1981 1032-PDT
From: Michael Dolbec <CSD.DOLBEC at SU-SCORE>
Subject: Re: Touchpanels vs Tablets
To: SAUNDERS at USC-ISIB, Joe.Newcomer at CMU-10A
cc: WorkS at MIT-AI, CSD.DOLBEC at SU-SCORE
In-Reply-To: Your message of 14-Jul-81 1014-PDT
The Alto set up has a mouse with 3 buttons ("bugs") for the
right hand, and a 5 key device for the left to play with.
There are text editors in Smalltalk that allow the mouse to
be used primarily as a pointing device while the key-set is
used to select actions and modes. So you see, devices exist
to keep the other hand busy also. I believe that Englebart
at SRI used a key set too. --Mike
------------------------------
Date: 15 Jul 1981 10:18:56-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: Saunders at isib
Subject: touch sensitive digitizers
Cc: WorkS at mit-ai
While using a touch sensitive digitizer (tsd) on a table
top wins in that you don't need to find a special stylus
with its clumsy wire, it suffers from the fact that other
objects, such as the palm of your hand, can set it off as
well. I heard that Elographics has a tablet that works
only with sharp objects. Has anyone had any experience
with it?
I am very wary of any comparisons made from theoretical
perspectives. In the long run, the most successful
input technique, whether tsd, tablet, or mouse, will
depend on which one "feels good" and works reliably.
As you pointed out, this depends a lot on how the
software is implemented.
------------------------------
Date: 15 Jul 1981 0843-EDT
From: WMACGREGOR at BBNA
Subject: Pointing Devices
To: works at MIT-AI
I agree with Steve Saunders position that touch panels
may not be as inferior as commonly assumed. Certainly mice
have their advantages, but they have problems too. Because
the machine cannot determine the absolute position of a
mouse, it is awkward, at best, to use as a digitizing device.
Tablets are much better, since a stylus can be traced over a
graph or map placed on the tablet.
Even though mice do not require dedicated desk space in
theory, I have seen many users place a plastic sheet on the
desk (some kind of heavy vinyl with a tacky-feeling surface)
to give the mouse good traction. If you're going this far,
there is little advantage over a BitPad-type tablet.
Joysticks seem to be dismissed out of hand, and on the
whole I agree. However, one variant of the joystick, the
'force stick', I suspect is comparable to a touch panel or
mouse if properly engineered. (A force stick remains in
one place, and produces an output proportional to the forces
exerted on it in the X and Y directions; they are usually
elastically mounted, so that they bend slightly, maybe 1/8"
maximum, when force is applied).
- Bill
------------------------------
Date: 15 Jul 1981 1304-PDT
From: Park at SRI-AI
Subject: PWS cursor control
To: works at MIT-AI
Suggestions for New Kinds of Cursor Controllers
by
Bill Park
SRI International
One of the recent developments in robotics is a thin, flat sensor
that can measure force distributions normal to its surface as well
as shear forces. It might make a very convenient, rugged, reliable
fingertip cursor control.
These devices can be fabricated as array sensors with resolutions
on the order of a millimeter. They are intended for use as tactile
sensors to be installed as "fingertips" on robot hands, e.g., to
adjust gripping forces to prevent slippage. People at M.I.T.'s
Artificial Intelligence Laboratory, among others, are building
and experimenting with them.
They are typically made by embedding layers of parallel flexible
metal conductors in a matrix of silicon rubber that has been doped
with granules of an electrically conductive material such as carbon
or silver. Local conductance of the material is then a function of
local stress. A microprocessor measures the resistance between
selected pairs of conductors to determine the stress distributions
throughout the material.
You could mount one of these sensors flush with the top surface
of the keyboard housing, and use it somewhat like a trackball as
follows:
(1) Whenever the operator touched it with a finger, the micro-
computer would determine the centroid of the distribution of
pressure exerted. (Using the centroid might overcome the
objection to high resolution in a touch-sensitive device to
be operated by a "fat finger.") The location of this centroid
would determine a corresponding coarse location on the screen
at which a cursor would appear. Rolling the finger slightly
or sliding it over the surface would allow fine adjustment of
the cursor position. This is a small-muscle task which I
believe would be easy to learn and to perform rapidly.
(2) Pressing harder on the surface could signal a special action
to perform at that point, such as placing a marker on the
screen or changing the mode of operation. Using modes (1)
and (2) alternatively, one could quickly place a sequence of
markers around a block of text or a polygonal region of an
image.
(3) Pushing the finger along the surface (producing a shear
stress signal) could then indicate a corresponding vector
in the plane of the screen. This could be used, for example,
to control cursor velocity or to move a previously delineated
region of the image around on the screen.
I think it might be most convenient to mount such a control on
the keyboard within easy reach of either thumb, such as on the
front edge of the housing below the space bar. One would then
not have to move one's hands at all to point at things on the
screen.
A much cruder device is available commercially. It is a linear
array of parallel electrical conductors. Stroking it produces a
bipolar analog signal. It is marketed as, e.g., a more rugged,
completely sealed replacement for a knob on a piece of military
electronic gear. Two of these could be mounted at right angles
to one another within reach of a thumb to control incremental
horizontal and vertical cursor motion.
Another possibility for minimizing hand motion would be to
incorporate a miniature 2- or 3-degree-of-freedom joystick
into the keyboard, in the form of one more, special, key.
Or even several such "joykeys."
------------------------------
Date: Thursday, 16 July 1981 03:28-EDT
From: Jonathan Alan Solomon <JSOL at RUTGERS>
To: Steve Saunders <SAUNDERS at USC-ISIB>
Cc: JSol at RUTGERS, JWALKER at BBNA, WorkS at MIT-AI
Subject: Touchpanel prejudice
Touch Panels! Touch Panels! Indeed. Give me the greatest touch
panel known to man, the Terminal Keyboard. Some of them even
come detachable.
Seriously, since the primary appeal for workstations will be to
users who already have some aptitude on computers, there should
probably be some correlation between touch panels and terminals.
(here I envision my briefcase-thin terminal with the touch panel
screen which doubles as a keyboard).
Jsol
------------------------------
End of Collected Responses on Touchpanels II
********************************************
Subject: Re: Picture vs. Window names
∂16-Jul-81 0604 Chris Ryland <RYLAND at SRI-KL> Re: Picture vs. Window names
Date: 15 Jul 1981 0911-PDT
From: Chris Ryland <RYLAND at SRI-KL>
To: works at MIT-AI
In-Reply-To: Your message of 13-Jul-81 1050-PDT
I recommend heartily that everyone stop wondering about window/session
managers until they read the four PIE papers now available from PARC,
by Ira Goldstein and Danny Bobrow. PIE provides most of the mechanics
for exactly the kinds of things people are meandering verbally around.
I'm referring to report CSL-81-3 from Xerox PARC. Also related, though
possibly not available yet, is CSL-81-4, ``PIE: An Experimental
Personal Information Environment.''
Subject: pukcba ekortsyek
∂16-Jul-81 0620 Frankston.SoftArts at MIT-Multics pukcba ekortsyek
Date: 15 July 1981 20:40 edt
From: Frankston.SoftArts at MIT-Multics
Sender: COMSAT.SoftArts at MIT-Multics
Reply-To: Frankston at MIT-Multics (Bob Frankston)
To: works at MIT-AI
*from: BOB (Bob Frankston)
Local: works at mit-ai
There are many naive ideas for backup that work in limited
contexts. The assumption of keystroke backup is that the
keystrokes are the only information needed. That might be true
in simple system. It is not true when one is interacting with
a more general environment. For example, inserting files from
a hierarchy using names relative to the current environment.
Or reading mail, or waiting for timeouts.
Subject: Making paper go away
∂16-Jul-81 0704 Joe.Newcomer at CMU-10A Making paper go away
Date: 14 July 1981 1211-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
In-Reply-To: gaines@RAND-UNIX's message of 12 Jul 81 18:14-EST
You've fallen into the same trap that most people do. If what you
want is the ability to scan quickly thru a document, this suggests
that a capability the computer should have is to scan quickly thru a
document. If you want to make notes, the computer should provide the
ability to make notes. If you want to doodle in color, the computer
should provide the ability to doodle in color. What you've stated is
not reasons for retaining paper, but a specification of what
capabilities we need in a computer if we want paper to go away.
Now current technology makes a lot of this extremely difficult. For
example, at very slow data rates (say, 9600, which is as close to DC
as one would care to get), it is unreasonable to browse thru most
large documents. With 24-line screens, finding enough context to
make sense of what has been typed is nearly impossible. But saying
that online retrieval will never replace paper is silly; it means
you've failed to adapt the computer to what people need.
The observation that it is useful to print things out on paper so
they don't have to be stored online is likewise looking at the
problem from the wrong side. What I want is a method of taking silly
pieces of paper and getting them onto the machine so I don't need to
store the paper! Fact: secondary storage is cheap, is getting
cheaper, and even primitive archiving techniques make it look even
cheaper. Why should I have to do something (file a piece of paper)
that the computer can do more effectively?
I keep all my source listings in hardcopy form. Why? Because it is
faster to look something up on hardcopy than online. Why? because a
24x80, 9600 baud terminal is too small and too slow to accomodate me.
If I had four or five 60-line screens with a typical effective
bandwidth (including disk latency, etc.) of about 100Kbaud, I
wouldn't need to print anything. One way of achieving this is to use
multiple windows, but it is not the only way (another is to have four
or five 60-line terminals).
If paper is more effective, then there is a mismatch between the
needs of the person and the software. I don't see anything which has
yet made that statement even suspect. What we need to do is explore
how to eliminate that mismatch.
joe
Subject: Programming by example
∂16-Jul-81 1052 Halbert at PARC-MAXC Programming by example
Date: 13 Jul 1981 10:35 PDT
From: Halbert at PARC-MAXC
To: WorkS@mit-ai
Here is a short description of programming by example. I
have gotten requests from a LARGE number of WorkS subscribers
requesting it.
------------------------------
Since a few people have mentioned programming by example and
the work I've done on it specifically, I will try to give a
brief outline of what it is, and what I've done:
At its simplest, programming by example is just recording a
sequence of commands to a system, so that the sequence can
be played back at a later time, to do the same or a similar
task. The sequence forms a program. The user tells the
system, "Remember what I am doing". The system executes
the user's commands normally, but also remembers them.
The user has created a program by giving an example what he
wants the program to do. However, the statements in his
program are the same as the normal system commands. The
user does not have to learn some programming language with
its attendant syntax and semantics; instead he can do his
programming -in the user interface- of the system, which he
already has to know anyway in order to operate the system.
In addition, he has written the program by performing,
concretely, an example of what the program is supposed to
do. Since he can easily verify whether he did his example
correctly, he can be fairly confident his program will work.
He does not have to understand his program abstractly.
Naturally, straight line programs without parameters are not
very interesting. Once the user has written a program he
may want to -generalize- it. He may want to print file Y,
instead of the file X he used in his example. So the system
has to provide a way for him to to change the constants in
his programs to variables, and specify how these variables
are to be bound (e.g. by prompting the user, by looking for
similar data, etc.)
The user may also want to insert conditional or looping
constructs into his program. There are various ways, which
I will not go into here, of inserting these constructs into
programs using programming-by-example techniques.
I would emphasize that this kind of programming by example
does not use inductive inference techniques used in AI,
in which the user does several examples, and the system
inductively determines what has changed from example to
example (e.g. 1+2, 5+2, hmm, first operand must be a
variable; or a[1], a[2], a[3], hmm, looks like a loop
stepping through the array).
The seminal work in programming by example was done by Dave
Smith of Xerox in his Stanford Ph.D. Thesis. Gael Curry
did similar work in which the examples given by the user
could contain abstract as well as concrete data values.
Certain industrial robots can be programmed by example by
guiding them through the task they are to perform. Here
at Xerox, I have added programming by example to a prototype
of Star. The system provides program generalization and
an iteration mechanism as well as simple command recording.
I have written up this work and my ideas on programming by
example so far in a Master's project report done for U.C.
Berkeley. I intend to continue and extend this work into a
Ph.D. thesis.
References:
Daniel C. Halbert. An Example of Programming by Example.
Master's project report, University of California, Berkeley,
and internal report, Xerox Corporation, Office Products
Division, Palo Alto, CA.
David C. Smith. Pygmalion: A Computer Program to Model and
Stimulate Creative Thought. Ph.D. thesis, Stanford University,
1975 and Birkhauser Verlag, 1977.
Gael A. Curry. Programming by Abstract Demonstration. Ph.D.
thesis, University of Washington, Seattle. Technical Report
No. 78-03-02. March, 1978.
Henry Lieberman and Carl Hewitt. A Session with Tinker:
Interleaving Program Testing with Program Writing.
Conference Record of the 1980 LISP Conference, Stanford
University, August, 1980. [describes a programming by
example system for Lisp]
Michael A. Bauer. Programming By Examples. Artificial
Intelligence 12: 1-12 (May 1979). [describes inductive
inference techniques].
Copies of my report are available on request.
Dan Halbert
Xerox Corporation
Office Products Division
3450 Hillview Avenue
Palo Alto, California
or
Halbert@PARC-MAXC (preferred)
(or csvax.halbert@Berkeley)
--Dan
-----
Subject: Re: Reliablity
∂16-Jul-81 1634 Bernie Cosell <cosell at BBN-UNIX> Re: Reliablity
Date: 15 Jul 1981 13:50:10 EDT (Wednesday)
From: Bernie Cosell <cosell at BBN-UNIX>
In-Reply-to: Your message of 13 Jul 1981 11:20 EDT
To: BHYDE at BBNG
Cc: Works at MIT-AI
I agree with Ben that the `real' accounting fellows really did figure
it mostly out (several hundred years ago!), with Journalizing and
autid trails and the like. I would like to make a tiny correction:
if I remember correctly from some accounting courses I took, double
entry bookkeeping has nothing really to do with the `journal' aspect:
the double entry name comes from the fact that both debits and credits
are simultaneously maintained and every financial transaction is fully
entered on both sides. Thus, at any moment, you can check a set of
books for a simple addition error by simply totaling up all of the
accounts and the balance should always be zero. (I think that this
is called taking a trial balance).
/Bernie
Subject: PIE reports from PARC
∂16-Jul-81 1811 Chris Ryland <RYLAND at SRI-KL> PIE reports from PARC
Date: 16 Jul 1981 1446-PDT
From: Chris Ryland <RYLAND at SRI-KL>
To: WorkS at MIT-AI
Since I've gotten quite a few requests for the PIE reports
I referenced, I'm forwarding the official requesting address
and the report identifiers:
CSL-81-3, Goldstein & Bobrow "An experimental description
based program environment - four reports" and
CSL-81-5 Goldstein & Bobrow "A layered approach to software
design" are available by sending a message to Jenkins@PARC
with your address.
Subject: Quickie poll
∂16-Jul-81 1825 Lloyd at MIT-AI Quickie poll
Date: 15 July 1981 2220-EDT
From: Lloyd at MIT-AI
To: WorkS at MIT-AI
How many people on this list are ACTIVELY hacking a personal
workstation in hopes of creating a real live 'office automation'
or 'executive information' system? I feel fairly certain that
the PARC folk are but how 'bout the rest of you?
Brian
P.S. It's OK to swamp my mailbox this time. I will pass the
results of my poll on if anyone is really interested.
B
Subject: Re: Making paper go away
∂16-Jul-81 1841 Zellich at OFFICE-3 (Rich Zellich) Re: Making paper go away
Date: 16 Jul 1981 0936-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
To: Joe.Newcomer at CMU-10A, works at MIT-AI
cc: ZELLICH
In response to the message sent 14 July 1981 1211-EDT (Tuesday)
from Joe.Newcomer@CMU-10A
Well, there is already a way to scan quickly through files:
it's called structured (or hierarchical, or whatever) files
a la Engelbart's NLS (now called Augment) and (Ted Nelson's ?)
Hypertext.
You can look at one or more levels, and independently one or
more lines of those levels, and open up or close up the part
on your screen to see more or less. It makes it very fast
to see what is in a document you've never seen before, or
to find something specific in an old document when you don't
know it's exact location. You may even be able to "address"
desired text by context. Combined with a windowing capability,
a pointing mouse, and auxiliary 5-key keyset, this gives an
extremely powerful tool - now if only it came packaged in a
briefcase-sized personal DEC-10...
Structured files are great, but do have an interface problem
because the rest of the world uses "flat" files - it's not
always easy to translate between the two - especially if there
is highly-formatted text like columnated tables, or "drawings"
(dot-and-dash boxes, etc.). Of course, the interface with the
rest of the world is a problem when using *any* advanced system
- I might have a little trouble putting a Star icon in a netmail
message, too.
-Rich
-------
Subject: Re: Making paper go away
∂16-Jul-81 1902 Joe.Newcomer at CMU-10A Re: Making paper go away
Date: 16 July 1981 1400-EDT (Thursday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
In-Reply-To: Zellich@OFFICE-3's message of 16 Jul 81 11:35-EST
One of the main problems in dealing with structured files is that
most operating systems give you "the files" and "the user space"
and you're on your own to figure out what to do with the files.
In Hydra, it was possible to define the text string transformation
of a file as part of the "subfile" type description. No matter
how peculiar the internal representation of the file might be,
the interface it provided to the outside world was a sequential
"flat" file suitable as input to a compiler or lister. Of course,
there were other interfaces which were presented; internally, the
editor for that file type was powerful enough to manipulate the
full representation. One could also have a "display" interface
by which illustrations were made visible on a CRT, or a "printer"
interface by which the file was presented in a form suitable for
printing (e.g., a Press file format would have been possible).
This is necessarily a simplified view, and we didn't begin to
explore all the problems, but the really important idea is that
at the basic interface, an ordinary program could NOT get at the
bits of the file. Only the bits presented by the file interface.
This abstraction is critical in protecting users from file repre-
sentations, and I consider any file system which does not support
at least this form abstraction to now be hopelessly behind the
state of the art.
I hope to do some more research in this area in the next few
years. The Hydra idea may NOT be the best, or even close to
right, but it is a whole lot better than any conventional file
system.
(In Unix, it is possible to use pipes to provide the transfor-
mation; a filter converts a complex file to a sequential byte
stream. Alas, Unix does not provide the protection necessary
to keep any random program from trashing the file by THINKING
it is a sequential byte stream file. Nonetheless, their heart
is in the right place. This is one of the reasons I think
pipes are a winning concept).
(The message based operating system for Spice, called Accent,
makes it possible to build systems with this style of
interaction).
joe
Subject: Making paper go away
∂16-Jul-81 1928 Vaughan Pratt <CSD.PRATT at SU-SCORE> Making paper go away
Date: 16 Jul 1981 1445-PDT
From: Vaughan Pratt <CSD.PRATT at SU-SCORE>
To: works at MIT-AI
If paper is more effective, then there is a mismatch
between the needs of the person and the software.
Joe's implication that any mismatch between people and computers
needs to be eliminated is similar to the attitude that gave rise
to the BART fiasco. This zeal to automate everything is misplaced.
Some products already do their job quite well. Paper, for example.
One thing I particularly like about paper is that I can leave
it on the beach while I'm swimming without being too concerned
that someone is likely to walk off with it. Is anyone willing to
predict which century will see portable computers able to compete
with paper as an improbable target of petty thieves?
A more appropriate attitude would be to keep an eye open for
opportunities where the computer can outperform the traditional
product. I suspect this is what Joe really has in mind when
he talks about automating paper. Paper has its disadvantages
as well as its advantages. Pen-and-paper is a poor medium
for speed of text input (many of us type twice as fast as we
write, though presumably not Steven Gutfreund, who says he
prefers mice and chordsets to 4-row QWERTY keyboards). Paper
is inconvenient to transmit, with a delay measured in days
rather than minutes. It is difficult to search associatively.
It does not lend itself to alteration. Making duplicates for
redundancy (e.g. guarding against fire etc.) is awkward.
Text and graphics macros (Letraset, stencils, french curves,
rubber stamps, etc.) are relatively inflexible. Conversion
to machine readable form is much harder than the reverse
direction.
The moral is that while computers outperform paper in some
categories, it is wishful thinking to imagine that it will
also soon come to dominate in all the remaining categories.
Needless to say, the moral applies equally well to other
products besides paper, e.g. BART drivers.
Applying this to AI, I would prefer to characterize AI
not so much in terms of passing Turing's test as looking
for additional human activities that lend themselves to
automation.
Subject: Re: Office of Tomorrow, where is it?
∂16-Jul-81 1947 Joe.Newcomer at CMU-10A Re: Office of Tomorrow, where is it?
Date: 14 July 1981 1222-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: DREIFU at WHARTON-10 (Henry Dreifus)
CC: works at mit-ai
In-Reply-To: DREIFU@WHARTON-10's message of 12 Jul 81 18:55-EST
I suppose you've heard of the idea of putting 2GHz packet
transmission repeaters on every commercial aircraft? The idea
is that there is hardly a moment when there isn't at least one
aircraft over someplace in the U.S., so the number of times
you would find the global network unavailable to your pocket
terminal should be fairly small...and of course, if you are on
the airliner, you should be able to use the facility as well.
joe
∂16-Jul-81 2007 Chip Maguire <Maguire at UTAH-20> Re: Office of Tomorrow, where is it?
Date: 13 Jul 1981 1617-MDT
From: Chip Maguire <Maguire at UTAH-20>
Subject: Re: Office of Tomorrow, where is it?
To: DREIFU at WHARTON-10, works at MIT-ML
cc: Maguire at UTAH-20
In-Reply-To: Your message of 13-Jul-81 0745-MDT
Over two years ago I spoke with the North American VP of
a large European airline, he was looking toward terminals
in the airplanes for both passanger use and for airline
reservations/info (because of the high degree of being late
screwing up large numbers of passengers schedules - let the
passengers change their reservations while circling JFK or
when making that suprise landing at Moline). His company
was also thinking of utilizing TELETEXT for reservations
in cities offering this service.
Chip
-------
∂16-Jul-81 2023 JWALKER at BBNA Re: Office of Tomorrow, where is it?
Date: 13 Jul 1981 0934-EDT
Sender: JWALKER at BBNA
Subject: Re: Office of Tomorrow, where is it?
From: JWALKER at BBNA
To: WorkS at AI
Message-ID: <[BBNA]13-Jul-81 09:34:24.JWALKER>
In-Reply-To: Your message of 12 Jul 1981 (Sunday) 1955-EDT
Why not on airplanes? Until the problems of electro-whatever
interference are more under control we won't be using terminals
on airplanes. As they explained on one flight I was on, the
kiddies couldn't use their electronic games because they
interfered with the plane's navigation equipment. So I think
it will be awhile before we beam communications out of the sky
to our home computers!
Subject: Icons and analogy
∂12-Jul-81 1804 BHYDE at BBNG Icons and analogy
Date: 10 Jul 1981 2252-EDT
Sender: BHYDE at BBNG
From: BHYDE at BBNG
To: Works at MIT-AI
Message-ID: <[BBNG]10-Jul-81 22:52:13.BHYDE>
It is not difficult to develop a sympathy for the
earlier comment that it seems sad to adopt as a primitive
of the automated office all of the curious mechanism of
the traditional paper mill. Three ring binders, electric
pencil sharpeners (where ones mouse regularly visits), to
calling cards.
There is a reason for this fundamental decision being so
popular in the community. I believe that I recognize in
this choice a pattern I first saw in the product lines of
the process control companies, product offerings always
mimic existing products. This seems to be a fundamental
truth of all marketing. If a product is completely new
then your customers will not be able to comprehend it,
they will not recognize it, it will be foreign, odd ball.
In the real time control community a very popular device is
the programmable controller, it replaces a relay controller,
its operation is specified with relay ladder diagrams. It
is implemented with a microprocessor, programmed on a video
terminal. The video terminal is often specially constructed
to be able to draw the ladder diagrams. I have heard sane
and successful providers of these devices talk of the new
model that includes as a standard component a speaker which
will generate the simulated noise of the relays clicking.
Once installed the plant foreman will never notice the
difference.
In creating a successful product one has to sell too many
groups of people, technical management, business management,
sales management, the sales men, and lastly the customers.
Each to these groups must be taught. Taught enough so that
they feel warm and comfortable about this new (and hence
suspect) product. If one can explain the product via analogy
then their rich body of experience ( hence trust ) with the
analogous situation can be used to leverage the short period
of time available to train them in.
What is this they cry! If you can't answer in one sentence
the sale is lost.
Ben Hyde
Subject: Redefining the art
∂13-Jul-81 0712 Brian P. Lloyd <LLOYD at MIT-AI> Redefining the art
Date: 12 July 1981 12:42-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: WORKS at MIT-AI
Yes, there are significant marketing reasons for not changing
the state-of-the-art too rapidly. Fortunately we do not need
to concern ourselves with what the customer expects. Look
at Xerox-PARC and the Alto system: I don't think that they
concerned themselves with market acceptance when they first
designed the Alto. Their experiences have brought them to the
forefront of the personal workstation and office automation
marketplaces. Ok, I accept "Star" as the current SOTA. I now
want to know what lies beyond. On a day-to-day basis I have
to stifle my creative urges in order to satisfy the needs of
a marketing organization. In this forum I want to discuss
future concepts.
Brian
Subject: Re: Re: A Quibble or two
∂13-Jul-81 0810 gaines at RAND-UNIX Re: Re: A Quibble or two
Date: Sunday, 12 Jul 1981 16:14-PDT
To: Joe.Newcomer at CMU-10A
Cc: works at MIT-AI
In-reply-to: Your message of 7 July 1981 1218-EDT (Tuesday).
From: gaines at RAND-UNIX
.... If using little pieces of paper is more effective than
using the computer, this indicates that something is very
wrong in the design of the software. Either the software
is good enough to replace paper, which is presumably the
intent, or somebody blew the design.
This implicitly states the view that paper is going to go away.
I don't believe it. As computer use increases in offices, I
think that we can expect that the amount of paper shuffled
will substantially decrease. But paper has its own uses. It
is easier to scan rapidly through a large report (or a printed
collection of junk messages from the Arpanet) that to do the
same on-line. It is wonderful to be able to write or draw, in
colors, on a printed page, including on top of the writing. I
can often find interesting things in a file cabinet when I'm not
sure just where I filed it than I can find things filed on-line
when I am faced with the same degree of uncertainty. I expect
that the evolution of office work brought on by intensive use of
computer works stations will cause many changes which affect how
and when paper is used, but will not eliminate it.
Incidentally, the one thing really needed is a cheap way to
read in a computer-printed piece of paper, so I don't have to
maintain the corresponding text on-line. If we had really cheap
large capacity stores so that things could stay on-line forever,
then it would be nice to copy anything printed to a retreivable
place, with the identification automatically printed on the piece
of paper so that if I delete it from my files, I can retreive it
again when I next look at the piece of paper.
Overall, I think we need more progress on getting the paper
and computer worlds to mesh together nicely, in contrast to
the objective of getting rid of paper.
Subject: Re: Spatial design for a workstation
∂07-Jul-81 0556 JWALKER at BBNA Re: Spatial design for a workstation
Date: 6 Jul 1981 2102-EDT
Sender: JWALKER at BBNA
From: JWALKER at BBNA
To: WorkS at AI
Message-ID: <[BBNA] 6-Jul-81 21:02:05.JWALKER>
In-Reply-To: Your message of 1 Jul 81 10:03:14-EDT (Wed)
My initial reaction to your scenario is that the idea of selecting
an operation is no different in essence from continuing a suspended
operation. E.G. selecting INBOX is exactly the same as continuing
a mail reader. The distinction is in being able to reinstate visual
context. This is an important distinction of course, being made
feasible by the new generation of hardware for displays.
One question though. This scenario description assumes that each thing
you can select has one "reason" for being selected. The INBOX being
selected means you are rummaging through it. Is this assumption likely
to hold? That is, will the reason for selecting something always be
unique or unambiguous enough that the right set of operations will
become available automatically?
Jan
∂07-Jul-81 0650 Zellich at OFFICE-3 (Rich Zellich) Re: Spatial design for a workstation
Date: 6 Jul 1981 1731-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Re: Spatial design for a workstation
To: WorkS at MIT-AI
I currently use a system that keeps track of the previous infile locations,
the previous file(s), and the previous programs/tools. It is very
handy to be able to do this, but it *does* have some drawbacks. One is
that there is a finite number of such things that can be kept track of,
so occasionally you lose track of the nth-back thing (the computer does,
anyway - you may still remember it yourself); the other main drawback is
that sometimes you *don't* want to keep track of everything you just did.
You can't win, really. Either the system tries to keep track of *everything*
and makes it really confusing to go back through the ring structures after
being online for a couple of hours, or the user must issue an
explicit command to either "save" or to "don't save" when interrupting to
somewhere else.
-Rich Zellich
-------
∂07-Jul-81 0721 DPR at MIT-XX Spatial design for a workstation
Date: Monday, 6 July 1981 09:39-EDT
From: DPR at MIT-XX
To: Rivanciw.DHQ at UDel
Cc: works at Mit-Ai
Subject: Spatial design for a workstation
Congratulations. It seems that you have just discovered the paradigm
of the Xerox STAR and Negroponte's Spatial Data Management systems. More
likely you knew about them already. With a little improvement in
Xerox's software, this could be the substance of an ad for STAR!
THe problem, though, is the same as the one on my desk--it get cluttered
fast with incomplete tasks. If certain tasks have long time horizons,
and certain ones have short time horizons, the result is a mess. If the
priority is not correlated with time horizon (since in my case there is
always more to do than can be done, requiring that some things NEVER
get completed), then the pile gets deeper and deeper. So now I need
three dimensions, and a way to hand tasks off to others in a partially
completed state if it looks like I won't be able to finsih them.
How does my secretary extract stuff from my "automated desk" and finish
it when I'm out--or conversely, how do I or a temp deal with her "automated
desk" when she's sick?
David
∂07-Jul-81 0748 Deutsch at PARC-MAXC Re: Spatial design for a workstation
Date: 6 Jul 1981 07:53 PDT
From: Deutsch at PARC-MAXC
Subject: Re: Spatial design for a workstation
In-reply-to: Rivanciw.DHQ's message of 1 Jul 81 10:03:14-EDT (Wed)
To: Rivanciw.DHQ at UDel
cc: works at Mit-Ai
As I mentioned before, the concept you mention is exactly the one that has
evolved at Xerox over the last 10 years and is (I believe) incorporated in
the Star in a form very similar to the one you envision. Of course, your
scenario includes a good deal more "polish" than the Star in terms of the
system being more intelligent about the relative priorities, default
desires, etc. of the user.
Subject: Re: Spatial design for a workstation
∂07-Jul-81 1035 cfh at CCA-UNIX (Christopher Herot) Re: Spatial design for a workstation
Date: 6 Jul 1981 13:06:26-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: Rivanciw.DHQ at UDel
Cc: works at Mit-Ai
In response to your message of Sun Jul 5 14:23:05 1981:
We built a system here for ARPA which incorporates
some of the facilities you describe in your scenario.
The system consists of a number of intelligent (8080-based)
terminals hooked up at 9600 baud to a PDP-11/70 running
Unix. The screen provides a window into a data surface
which contains icons of various shapes. The outlines of
the icons are made up of standard printing characters.
The user can scroll the data surface by pressing an arrow
key (8 are provided to allow diagonal motion) or an
outboard joy stick.
The icons are user-defined and can correspond to any
program runnable under Unix. To run the program, the
user centers its icon on the screen and presses an
"activate" button. Typically, the program to be run
is the Ned (Rand ->BBN) display editor editing some file.
The user can return to the top level via either of two
buttons - "deactivate" or "detach". The "detach" button
suspends the program and causes the icon to blink. When
the user again activates that button, the screen is restored
to its previous state. I agree that it would have been
better to make "detach" the standard mode, but this was
not practical under Unix with the implementation approach
that we had chosen.
We haven't tried the system in an actual office environment.
Programmers found it cumbersome because there was always a
Unix command that didn't yet have an icon, and they already
knew most of the command names anyway. It usually took more
time to scroll to the icon than to type its name. People
always enjoy the demo however, and we are still looking for
a place to try it out.
Subject: Collected responses on terminal input devices
∂19-Jul-81 1612 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected responses on terminal input devices
Date: 19 July 1981 10:00-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
This collection of 9, relatively short messages continues the
WorkS discussion of interchangeable keyboards, touchpanels,
and other terminal input devices.
Enjoy,
RDD
------------------------------
Date: 17 July 1981 12:17-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
Subject: chordsets
To: csd.pratt at SU-SCORE
cc: WORKS at MIT-AI
Actually I don't know how I would feel after using a chordset
all day. What I am interested in is finding an alternative to
QWERTY input. There must be something with better ergonometrics
than a matrix of keys laid out to suit 18th century designers
of mechanical devices.
- Steven Gutfreund
------------------------------
Date: 18 July 1981 07:50-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
Subject: Interchangeable keyboards
To: SHRAGE at WHARTON-10
cc: WORKS at MIT-AI
The Convergent Technologies system has the ability to change
the keyboard encoding and the font on the display. We have
experimented with AZERTY, Dvorak, and special purpose
keyboards. We have used the unencoded mode of the keyboard
to simulate a chord keyboard. The only thing we lacked was
a simple way to relabel the keys (do you have any concept of
how difficult it is to make 98 little self-adhesive labels
and stick them on your keyboard every time you make a change?).
I would be interested in the re-label-able keyboard if you get
more info.
Brian
------------------------------
Date: 18 Jul 1981 (Saturday) 1148-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
Subject: LCD interchangeable keycaps.
To: lloyd at MIT-AI, works at MIT-AI
Well, let's let our imaginations run wild for a moment. It might
be possible to construct a 50x50 (or even less could do it) LCD
display with individually addressable points. Since the time
that an LCD takes to fade is very long, a rather slow Z80 would
be able to keep up with the updating of 50 or 60 of these. The
problem is really in fabricating the LCD and in wiring the keys
since there would have to be all these wires to each key (LCD is
not XY addressable as far as I know). The trick is to minimize
wires to the key. Typically this is done by putting encoding
onboard (onkey). Then we would only need two or three wires to
each key. I would think that if someone set their mind to it the
technology exists to do this job right.
Here are two other alternative in case you don't happen to have
an LCD fabrication plant in your back yard:
(1) put LCD strips just above the separated rows of keys. The
problem here is that the separation of the keys could make
it rather difficult to type.
(2) Train people to type on totally blank keys by reading a
"keyboard icon" that is ALWAYS displayed at the bottom of
the screen. This is my favorite idea and I'll bet that it
is not hard to so train typists. Well, give it a try and
let me know what you discover.
-- Jeff
------------------------------
Date: 18 July 1981 23:17-EDT
From: Brian P. Lloyd <LLOYD at MIT-MC>
Subject: LCD interchangeable keycaps.
To: WORKS at MIT-MC, SHRAGE at WHARTON-10
CT has an interesting keyboard diagnostic along the lines you
proposed. The program displays a facsimile of the keyboard on
the screen, and echoes what you type by turning the corresponding
key reverse video. It even shows whether or not the LEDs on
the keys are lit. I see no reason that this display couldn't
be shrunk and placed in its own window at the bottom of the
screen.
Good idea you had!
Brian
------------------------------
Date: 16 Jul 1981 20:53:37-PDT
From: CSVAX.rob at Berkeley
Subject: Tablets, mice, etc.
There is a very nice tablet available from Kurta Corporation
(206 S. River Dr., Tempe, Arizona, 85281 (602)968-8709). It
comes with either a parallel or serial interface, so if you
choose you needn't decode 9600 baud ASCII (a major break-
through...). It's about 8"x11", and if you ask for the Bell
Labs cursor you'll get a 3-button cursor much like a mouse.
We have a couple here, and are pleased with them. People
using them mostly feel they prefer the tablet to a mouse.
Rob Pike (research!rob@berkeley i think. or (for sure) robt@mit-mc)
------------------------------
Date: 17 Jul 1981 18:44:25-PDT
From: decvax!duke!unc!smb at Berkeley
To: duke!decvax!ucbvax!WorkS@MIT-AI
Subject: touching mice
I'm not too crazy about any of the pointing systems I've seen
described here, because I don't like having to take my hands
off of the keyboard. Besides, menus tend to have too few
options (can you imagine a menu for the UNIX command set) and
they impede the user who knows what he/she wants to do next.
But there seem to be enough folk out there who LIKE to worship
icons, so.... an idea I've seen suggested for a pointing device
is a light pen that's worn as a thimble or attached to a ring.
One must still remove a hand from the keyboard, but at least
there's no need to grope for squirmy mice. This idea works
best, it would seem, in situations where there's a fairly
large amount of pure text work, as well as commands -- say,
a text editor.
--Steve Bellovin, UNC, Chapel Hill
------------------------------
Date: 16 July 1981 13:54 edt
From: MPresser.Multics at MIT-Multics
Subject: Tracking balls
To: WorkS at MIT-AI
In-Reply-To: Message of 15 July 1981 09:32 edt from Joe.Newcomer
I have used a reasonably good tracking ball on a system that
did the automatic recognition of human chromosomes. Every
so often, the system would get confused and not be able to
separate two chromosomes that were, or appeared to be touching.
The ball was used like a scissors to cut the surface, so that
two disconnected objects appeared. Our ball was homemade, and
the most circuitous of cuts to be made in next to no time.
The principle used was that of extreme gearing down, so that
very fine motions could be made. For these purposes, the
thing was very useful. I'm not sure how it would have worked
for menu manipulation. We used the terminal keyboard for that.
------------------------------
Date: 16 Jul 1981 0924-PDT
From: Chris Ryland <RYLAND at SRI-KL>
Subject: Bill Park's message
To: WorkS at MIT-AI
In-Reply-To: Your message of 16-Jul-81 0400-PDT
Bill Park's message mentioned what I believe XEROX marketed as a
"cat" on the 850-series word processors: a small area which you
stroke to move the cursor. Since these systems were fixed-font
oriented, I don't know if these cats would be useful in a more
high-resolution environment.
------------------------------
Date: 18 Jul 1981 (Saturday) 1110-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
Subject: Visionary terminals
To: minsky at MIT-AI, works at MIT-AI
If you sneeze does it blow all the icons off the screen?
------------------------------
End of collected responses on terminal input devices
****************************************************
Subject: Bell Labs "writers workbench"
∂19-Jul-81 1613 mike at RAND-UNIX Bell Labs ''writers workbench''
Date: Saturday, 18 Jul 1981 12:43-PDT
From: mike at RAND-UNIX
To: works at MIT-ML
As has been mentioned, Bell Labs has put together a "writers
workbench" which is a set of tools to help detect and correct
common errors. Along with a spell program, there is also a
program to correct "bad diction", along with an "explain"
program which acts as an interactive thesaurus.
If you are interested, send me a message and I will forward
off the manual page.
Michael
Subject: writing aids
∂19-Jul-81 1614 Lauren at UCLA-SECURITY (Lauren Weinstein) writing aids
Date: 18 Jul 1981 0218-PDT (Saturday)
From: Lauren at UCLA-SECURITY (Lauren Weinstein)
To: ELLEN at MC
CC: BUG-EMACS,WORKS at AI
While I cannot help you with EMACS, there is a package of
programs running under Unix called, I believe, the "Writer's
Workbench". These programs do all sorts of neat tricks, like
looking for "awkward" sentence construction, overused or trite
words and phrases, and all sorts of similar actions. Kinda neat.
--Lauren--
---
Subject: Realtime proofreaders
∂19-Jul-81 1615 SHRAGE at WHARTON-10 (Jeffrey Shrager) Realtime proofreaders
Date: 18 Jul 1981 (Saturday) 1130-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
To: ellen at MIT-XX, works at MIT-AI
I think that one would lose a great deal of the effect of "offline"
proofreading if the system did much of that work in realtime which
the text was being entered. The clearest argument against that type
of system is that you are supposing that the errors are entirely
detectable from PREVIOUS context. Why should that be so? If you
are not assuming that then at what point do you extract and test?
Coherence is not a clearly distinguishable effect at any given level
(sentence, pgh, etc). Additionally, coherence and intention are
understanding effects. It is not clear that they can be extracted
without a rather fancy knowledge acquisition and utilization system
-- not to mention a grammar and semantics analyzer to front end the
thing (neither of which we are very comfortable with yet). Lastly,
more concretely, having a lot of little aid demons around it okay to
a point. You have to avoid the mistake that Twenex makes in being
overhelpful -- I wish that I could disable the space-delimiter help
system that keeps telling me that TPYE is not a legal command before
I've had a moment to back up over it and fix it!
Subject: Configuration
∂19-Jul-81 1617 BHYDE at BBNG Configuration
Date: 16 Jul 1981 1445-EDT
From: BHYDE at BBNG
To: WorkS at MIT-AI
Message-ID: <[BBNG]16-Jul-81 14:45:00.BHYDE>
There seen to be a clusters of similar designs for work stations.
One group is into bit slices and microcode tuning of instruction
set and i/o drivers. Another group seems to be into integrating
state of the art leading edge lsi and i/o devices into an expensive
terminal/computer ala 68000, winchester, and bit map. A smaller
group seems to be into building (the low rider community) super
personal machines a small cluster of 6809 which is a very smart
terminal mostly.
Is there a right answer here?
There seem to be various configuration control designs, the
strongest group seems to be big into 10 Megabit shared medium.
Why is 1 Megabit not good enough, what's wrong with 9600 baud
phone connections, what is so hot about shared medium designs
verses say a local store and forward design with twisted pair?
I don't understand how the configuration problem got standardized
to 10 Megabit shared medium so quickly?
People seem to be very excited about getting rid of the computer
center. I remember the pleasure of discovering that some one
else worried about backup, maintenance, selecting the standard
editor, etc. I believe these places have been called centers
of excellence. The work station architecture seem to be going
in the other direction, for what I believe are marketing reasons
not technical ones. Are there technical ones?
Are new forms of service centers going to appear in the
community? Are we going to see a high speed/quality printing
center in Chicago with one day mailing turn around and very
low cost per page? Are we going to see file backup whales
offering competing cost per bit archiving spread around the
nation? Federal expressing a four color document would add
very little to the cost of a hundred page one time printing.
If I offered a intercity file transfer with one day delivery,
and very low cost would there be any buyers?
All of these questions are the same meta question, how are
systems like this going to be configured, at the office level,
facility level, city level, and national level. Where will
the economies of scale fall out? What is the unit dollars
available at each layer?
Ben Hyde
Subject: [don: EP]
∂18-Jul-81 0044 Dave Crocker <dcrocker@udel> [don: EP]
Date: 17 Jul 81 12:49:40-EDT (Fri)
From: Dave Crocker <dcrocker@udel>
To: WorkS at Mit-Ai
cc: Don at Rand-Unix
Don Waterman has done work similar to Halbert's and said he
would not mind my forwarding the enclosed citations.
Dave
----- Forwarded message # 1:
Date: Thursday, 16 Jul 1981 16:09-PDT
To: Halbert at PARC-MAXC
Subject: EP
From: don at RAND-UNIX
Dan: I saw a brief description on your Exemplary Programming work
and thought you might be interested in similar work done here at
Rand a few years ago. The references are:
Waterman, D. A., Faught, W., Klahr, P.,Rosenschein,
S., and Wesson, R. Design Issues for Exemplary
Programming. In Automatic Program Construction
Techniques, Biermann, G., Guiho, G., and Kodratoff,
Y. (Eds), MacMillan, In Press.
Faught, W., Waterman, D. A., Rosenschein, S., Gorlin,
D., and Tepper, S. EP-2: A Prototype Exemplary
Programming System. Rand Report R-2411-ARPA, 1979.
Waterman, D. A. Exemplary programming in RITA. In
Pattern-Directed Inference Systems (D. A. Waterman
and F. Hayes-Roth, Eds.). Academic Press, New
York, 1978.
plus a few others. I can send you copies of the papers if you
are interested.
Regards,
Don Waterman
----- End of forwarded messages
Subject: Alternatives to making paper go away
∂18-Jul-81 0106 SHRAGE at WHARTON-10 (Jeffrey Shrager) Alternatives to making paper go away
Date: 16 Jul 1981 (Thursday) 2305-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
To: works at MIT-AI
An alternative to hierarchical file structures for quickly perusing
bulk data: We once tried to implement a fancy solution to this
problem on a rather fancy piece of VG 3-D graphics equipment. Hook
the Z axis into the velocity of a joystick so that the faster you
move the farther away from the text you get. [Actually it isn't
quite as simple as that -- there are various tuned lags that have
to be implanted in order to give the user a chance to respond to
the modifed view, etc]. The effect is that of flying a helicopter
over your text and automatically zoom down for a close up when
you've decided that you're in the right part. I have never seen
a device less fancy than the VG that can respond and redraw quickly
enough to do this properly. The VG is a very high speed vector
graphics display that isn't really built for text work. It has a
stylus pad/light pen/knobs/buttons/full+keyboard (sorry, no meta
keys)/ and the nicest vector display around but it's really for
pictures, not text -- shame about that. Anyhow, we started to
do this and I got sick of having to deal with Fortrash and the
VG internal coding language after about a week so it never "flew"
but it was a nice idea. The real advantage is in reviewing huge
chunks of text (like the Unix manual) that are in some order (say,
alphabetically) because the text is still in front of your face
but the letters are smaller (and you get more of them on the page)
when you zoom out.
Subject: Re: Making paper go away
∂18-Jul-81 0130 Joe.Newcomer at CMU-10A Re: Making paper go away
Date: 17 July 1981 1246-EDT (Friday)
From: Joe.Newcomer at CMU-10A
To: Vaughan Pratt <CSD.PRATT at SU-SCORE>
CC: works at mit-ai
In-Reply-To: Vaughan Pratt's message of 16 Jul 81 16:45-EST
Actually, your example is quite amusing. We were recently at a
conference at Pajaro Dunes. One of our participants was walking
along the beach during one of the interludes, and left his book
on the beach while he went into the water. When he came out, he
found that someone had stolen his book.
Yes, paper is more effective for some things RIGHT NOW. While I
don't believe automating blindly is a good idea, for most values
of use of paper I would prefer to use a computer. Even if I
produce hardcopy so it can be carried around, read on beaches and
busses, etc., I prefer to produce it via the computer. There are
lots of cases where paper is more convenient ONLY because of limi-
tations of the computer (e.g., 9600 baud slow lines). And when
computers will cost only $8.95 (or free with a deposit of $500),
there will be far less reason to walk off with one. We have to
quit thinking as if computers will always be expensive, and decide
what we can do with them when they are not. In fact, assume the
cost of the computer is ZERO. Now, what would you LIKE to do with
a computer? What capabilities should it possess at the interface?
Assume a communication cost of ZERO. How would you like to commu-
nicate with other computers? Now, at any given instant we have
to temper these ideas by the rather nasty fact that computers and
communications really do cost money. But that should NOT limit
our imaginations. A Dorado is a good example of what happens if
you let ideas not be limited by technology, and technology comes
along. Things which were unbelievably bad to run on an Alto run
just fine on a Dorado.
Don't tell me automating everything is bad. I don't believe it.
Automating everything INCORRECTLY is bad. I'd rather worry about
how to do it right, even if right isn't possible, than to not
think about the problem because this year's technology can't
support it.
joe
Subject: Scanning structured text
∂18-Jul-81 0150 Bob Hyman <HYMAN at DEC-MARLBORO> Scanning structured text
Date: 17 Jul 1981 1447-EDT
From: Bob Hyman <HYMAN at DEC-MARLBORO>
To: works at MIT-AI
Message-ID: <"MS5(1715)+GLXLIB1(1033)" 11744780684.17.399.17489 at DEC-MARLBORO>
The static structure of text rarely matches its "content",
except for artificial cases like program sources. Most
of the time, the salient features of a document, which
are the ones I'd like a structured editor to key on, are
dynamically defined by the reader. Until such a symbiotic
system is available, the artificially imposed structure
of the presentation is likely to impede comprehension,
not expedite it.
The alternative is to agree on a canonic form for a class of
documents, and for authors to conform their contribution to
the mold. This solution makes discussion of the canonic form
difficult, and is probably sufficiently restrictive to repel
prospective contributors on other topics as well.
Bob
Subject: Editing
∂18-Jul-81 0211 V. Ellen Golden <ELLEN at MIT-MC> Editing
Date: 14 July 1981 03:12-EDT
From: V. Ellen Golden <ELLEN at MIT-MC>
To: BUG-EMACS at MIT-MC, works at MIT-AI
cc: ellen at MIT-XX
As is often my occupation, I am indoctrinating a new user to
EMACS. She (factual, please do not accuse me of sexism) asked
after a couple of hours of EMACS-power, if it would be possible
for "it" ("The Computer", i.e. a program) to warn her while she
is typing a text, that she has used the same word repeatedly.
I pointed out to her that (a) many words in English repeat because
they are common (parts of the verb to be for instance) (b) some
words need to repeat, like "pathologist" because of the technical
nature of the text, and thus to chose between "facts" and "data"
in discourse might be hard, or to warn her that in the last two
paragraphs the word "experimental" had repeated 6 times might not
work. However, her problem is understandable in English terms:
she is typing up notes for a doctor. He wants to write "well",
which to him means not to repeat himself, which means not using
the same word over and over again, unless it is a technical term
(a distinction he may recognize but I am not sure). His hard-
working secretary is trying to help him, and now that she knows
how much EMACS can help her in just the typing up of his notes,
she is asking for what she sees as the next step, a program
to help her with editorial corrections... (i.e. "How many
times have I used "practical"... should I get out the thesaurus?"
-- next step of course is to provide the thesaurus, but let's
concentrate on repetition of non-common but non-technical words
in text).
Any thoughts on this?
And my comment, to everybody, "BUG-EMACS", and "Work Stations":
See, secretaries are NOT a sub-species of homo-sapiens, they in
fact often request the most sophisticated features from their
editors, justifiers, work stations, etc. In fact, some of them
are even willing to work on programming the features they want
(they do know the specifications, after all!).
Subject: Writing English
∂18-Jul-81 0230 JWALKER at BBNA Writing English
Date: Tuesday, 14 July 1981 22:34-EDT
From: JWALKER at BBNA
To: Ellen at XX, WorkS at AI
CC: Bug-EMACS at AI
I have for several years wanted to write a system with the goals
you described in your note to Bug-EMACS and WorkS. (No funding
has materialized though.)
Some work has been done on the problem by people at Bell Labs.
See the paper by Lorinda Cherry in the June issue of SIGPLAN
Notices. Still the real problems are those that you pointed
out. How can a computer know your reasons for word choice?
What is it possible to do without trying to implement a system
that "understands" free text? (Good writing is more a matter
of taste than of strict rules. Of course, if mediocre writers
follow a set of strict rules, they are more likely to produce
good writing than if they ignore the rules. But that's part
of a different argument.)
I have a few EMACS functions that were designed to help in
finding and correcting common problems -- changing "which"
to "that" (if you care) and "may" to "might" or "can" (may
is ambiguous). I'd like to hear from other individuals who
have written functions to help with the job of writing as I
am working on a technical writing environment.
Jan
Subject: Ideal word-processor
∂18-Jul-81 0250 Robert Elton Maas <REM at MIT-MC> Ideal word-processor
Date: 15 July 1981 03:14-EDT
From: Robert Elton Maas <REM at MIT-MC>
I wish EMACS/RMAIL had this, but maybe if I suggest it this
feature will be installed in some future text-processing system:
You're rapidly typing new text into this editor program. As you
type, in parallel with your typing, the spelling&grammar-corrector
is checking your text. When it finds an apparent error it flags
the error and indicates alongside it a suggested correction.
Any time you want, without having to manually put the cursor back
there and manually make the correction, you may enter one of three
commands:
Stet (ignore the error, let it stand without correction)
Ok correction (make the correction it guessed at)
Repair manually (automatically put cursor there, then you
manually fix it however you want, then if the spelling
corrector still doesn't your fix it shows its new best
guess at correction and leaves the cursor there, so you
can Stet or Ok or Repair again)
After satisfying the flagged apparent error by Stet or Ok, it
shows you the next apparent error if there is any pending; but
you may just continue typing normally if you don't feel like
handling the new apparent error immediately. If you're a bad
speller, what you'd probably do is type a half a screenful
then sit there giving the Ok command for a whole batch of
errors it found, then go back to typing. Thus you wouldn't
have to constantly check your typing to see if keystrokes were
lost or words you're not sure of were wrong. If both the word
you typed and the suggested correction were wrong, but you're
lazy (it isn't an important document nor a submission to a
mass-mailing such as WORKS, just an informal note to a friend),
you could just Stet the error if it's not too gross. You could
even let the suggested corrections roll off the screen, not
bothering to even check them for grossness, if you're really
in a hurry (thus it would degenerate to what we have now if
you choose not to actually use the info the spelling-corrector
gives you).
With a Xerox-Smalltalk style of user interface, you could easily
random-access the suggested corrections, manually fixing the
gross ones and then Steting or Oking all the others en masse.
["Automate the Business Office--How and When"]
∂18-Jul-81 0311 ROBERTS at USC-ISI
Date: 15 Jul 1981 1941-PDT
Sender: ROBERTS at USC-ISI
From: ROBERTS at USC-ISI
To: WorkS at MIT-AI
Cc: roberts
Message-ID: <[USC-ISI]15-Jul-81 19:41:39.ROBERTS>
Interesting quote (attributed to an article in the "Siemens
Review") in this month's issue of "Telecommunications" magazine,
which has an article entitled "Automate the Business Office--How
and When":
"When new functions are added to an integrated work station, the
number of system components increases negligibly because existing
typewriter keyboards already possess keys for function selection,
and the function keypad will be expanded to allow the selection
of communications forms. The flat video display, designed to sit
on the desktop, is used for text preparation with correction and
editing function, the input and output of texts into memory, and
the input and output of texts to be transmitted. The flat screen
is the input/output medium for videotex, interactive videotex,
cable television, storing data from the user's own integrated
work station, and for departmental or central data-processing
systems. Finally, it also serves as the output medium for the
picturephone and video teleconferencing, for which an additional
camera, microphone and loudspeaker are incorporated into the work
station."
Now that's what I call a workstation! Comments, anyone?
Carlos Roberts
Subject: Talking Workstations, that elusive 'external device'.
∂18-Jul-81 0338 DREIFU at WHARTON-10 (Henry Dreifus) Talking Workstations, that elusive 'external device'.
Date: 17 Jul 1981 (Friday) 2127-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: works at MIT-AI
o Introducing Talking Workstations, Part II in presentation series
For some time, people have been doing research and development in
speech recognition.
As the 'locator device' why not voice recognizer?
While I am in my screen editor, I could say 'INSERT' or 'UPSCREEN'
rather than the key strokes.
I could say 'SEARCH' then it would prompt me for a search string.
In addition a key should be provided to toggle this feature on
and off. Imagine a demonstration saying Search or Reverse Screen
and your presentation is forever doomed.
Comments and ideas are being explored by a research group here
at Penn in this area. We'd like to know what the Works community
feels.
Subject: mice,balls,touch-plates,pens.
∂18-Jul-81 0354 MINSKY at MIT-ML mice,balls,touch-plates,pens.
Date: 18 July 1981 01:20-EDT
From: MINSKY at MIT-ML
To: WORKS at MIT-ML, MINSKY at MIT-ML
I feel that the pen-mouse-ball discussion is reactionary --
though many of the ideas are realistic and practical. But all of
them look back to non-interactive sensors of the past. Suppose
the terminal could SEE the user -- using a couple of little
vision-boxes. Then (i) it could watch your hands. You could
point to your icons on the screen in a really natural way. A
tracking cross would permit higher resolution, and the cursor
would move at a rate, say proportional to some power of the
distance between where it is and where you point. Then, one
could use some more AI to distinguish "intentional" hand motions
from tremors, etc. A smart such box could watch your eyes and
face, too.
If you like holding a pen, that too could be wireless -- because
the vision system would track its point. Such systems could work
in three dimensions. The vision box would observe your
eye-point. When you move your head, the various windows would
move in accord with 3-d occlusions, and this would permit more on
a cluttered desk than the usual methods -- moving your head a
couple of inches to the left would uncover the next layer below
on each stack -- etc.
Given a lot of R&D, such gadgets could be made in the next few
years, and would be as important as speech inputs. We need a
"terminal vision machine" project. Also, aren't the CRT schemes
rather reactionary, if flat TV stuff is coming in the next year
or two? Instead of vertical displays we can soon have (i)
desk-surface displays for near vision and (ii) wall projected
screens for far vision.
Subject: Re: Configuration
∂20-Jul-81 0737 Steve Crocker <Crocker at USC-ISIF> Re: Configuration
Date: 19 Jul 1981 1344-PDT
From: Steve Crocker <Crocker at USC-ISIF>
To: BHYDE at BBNG, WorkS at MIT-AI
In-Reply-To: Your message of 16-Jul-81 1145-PDT
Ben,
I don't think it's a fair reading of the present situation
to suggest that computer centers are "going away" in favor
of personal workstations. A better view is that the computer
center is becoming distributed and more easily incremented.
A lot of this is dependent on the specific cost of providing
service in any given technology. Today's costs make it
relatively cheap to provide a noticeable amount of computing
power to each person in the form of an individual workstation.
This means that the cost of separate packaging is less than
the cost of multiplexing several users onto the same (large)
machine. It's quite possible for this to shift back the other
way, though not likely, in my opinion.
Several things do remain centralized, and properly so:
a) file servers, high-quality printer/plotters,
long distance communication;
b) maintenance;
c) system development (hardware and software).
Your scenario of using a service in Chicago with overnight air
service is not only reasonable but entirely usual. There are
indeed services that are expensive enough to absorb the cost
of long-distance delivery. Various forms of fancy printing,
as you mentioned, is one; transcriptions of stenographic tapes
is another. I'm sure there are others.
Getting back to individual workstations, my own view is they
offer one big plus and one important trap. The big plus is
that the economics of adding a new user to "the system" is
much clearer. The classical time-sharing environment essen-
tially forces overloading of the machine, and we commonly see
environments where only the trivial tasks can be done during
the day and the heavy-duty tasks are delayed until evenings
or weekends. Unfortunately, it's these heavy-duty tasks that
are the reason for the facility and the people in the first
place. (Yes, I know this can be seen as a straight case of
mismanagement. Nonetheless, it's where things are.) With
computation tied to terminals, it becomes essentially
impossible to add people without adding capacity. (There's
always the possibility of "sharing" workstations. This may
be useful in some cases, but it will be clear to all that
when a person does not have access to the workstation, he
does not have access to anything. Compare with today's
situation where everyone has a terminal, but that doesn't
guarantee access to anything substantive at all.)
The trap in all this is there is a far sharper limit on the
size of the task that can be carried out with a workstation.
A lot of important tasks use more of the cetral facility than
the nominal capacity that is being doled out in workstations.
That will mean that transition from a small task fitting on a
workstation to a larger task that requires a different machine
will be relatively painful.
Steve
-------
Subject: Collected Responses on Terminal Input Devices
∂20-Jul-81 0838 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected Responses on Terminal Input Devices
Date: 20 Jul 1981 08:00-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
------------------------------
Date: 20 July 1981 07:00-EDT
From: sdcsvax!norman@NPRDC
Msgname: norman
To: works@mit-ai
Subject: keyboards should get changed, maybe
Marvin Minsky suggests that it is unimaginative to worry about
track balls and mice, light pens and touch screens, when visual
sensors can interpret your finger and eye motions so that you
need not lift your fingers far off the keyboard. Keyboard?
You mean the good old qwerty keyboard, arranged in 1873 by the
Sholes brothers to minimize jamming of the big lever arms on
the keys as they made their way to the platen? That triumph
of technology over common sense? Well, if you want to be
imaginative, why stick with qwerty keyboards?
The answer, by the way, is not to be found by simply rearranging
the keys. It turns out that qwerty is not so bad. The scheme
the Sholes brothers used to minimize clashes put the keys for
frequently typed bigrams far apart, meaning on opposite hands,
which we know today means faster typing. Lots of people have
fiddled with keyboard arrangements; its not worth the fuss.
Dvorak did a time and motion study analysis in the 1930's and
only improved typing speed by about 5% (some have claimed more
improvement; this figure comes from experiment, by computation,
and by a typing simulation program that we have developed). (In
similar ways, azerty and alphabetical arrangements don't lead to
much difference -- about 2 to 5% decrement.) And several studies
of beginners using alphabetically organized keyboards show no
improvement over qwerty. (Paper available on request.)
The current keyboard is hard to learn (several months to get to
speed), a surprisingly large proportion of people in this country
cannot type, and the top speed is limited by a combination of
physiological/anatomical factors and keyboard layout. Chord key-
boards, as used by court stenographers, go considerably faster
(they type syllables, with several simultaneous keystrokes), but
this takes even longer to learn (years), and it isn't easy to
decode as the users develop their own code for many words.
(On-line decoding can and has been done.)
BUT, why have 4 rows of keys? Why have a space bar that takes
up the whole row and is used only by the right thumb? Why not
allow upward movements as well as downward ones to be meaningful.
Why not allow multiple strokes to have meanings. Why so big?
The current size and the funny diagonal layout is determined
by historical mechanical constraints and violates the natural
mirror-image symmetry of the hands. Fitts law states that the
time to move the hands is linearly related to log(D/P) where
D is the distance to be moved and P the precision required.
You will gain a lot if the keyboard is made smaller and if
sloppiness in target location is allowed. Eliminating the
need to type RETURN on a line can speed up typing a much as
30% (our high speed films show the hand must distort itself
rather badly to get to the RETURN).
Would speech input be easier? Probably not, but a combination
of a sophisticated keyboard plus speech might be very effective.
How about tiny mice mounted on the keyboard where the thumbs can
reach them, or worn on rings, or available on a "roof" just above
the keys so that lifting the hands a fraction of an inch contacts
them. Or consider inserting the hands into gloves (wear your
keyboard) with touch and force sensitive fingertip sensors and
let hand configuration select the word and/or cursor placement.
And so on. The point is, it is time to change the keyboard,
and not just by rearranging the keys; that won't buy anything.
don norman (norman@nprdc or ucbvax!sdcsvax!norman)
------------------------------
Date: 19-Jul-81 17:08:04 PDT (Sunday)
From: Hamilton.ES at PARC-MAXC
Subject: Re: Talking Workstations, that elusive 'external device'.
In-reply-to: DREIFU's message of 17 Jul 1981 (Friday) 2127-EDT
To: DREIFU at WHARTON-10 (Henry Dreifus)
cc: Hamilton.ES, works@AI
I'd like to preserve my vocal cords, thank you. Not to mention
the fact that not everyone has a private office. I can deal
with the clack of my officemate's keyboard and the hum of his
disks, but I don't think I want to hear him muttering to his
computer all day.
I think that something along the lines of what Minsky was
suggesting would be more appropriate -- we could make much
greater use of technologies that have been heretofore
reserved for the handicapped, such as breath control, eye
control, etc. Also, I really like the idea someone suggested
a few days ago of placing lotsa special input devices just
below the spacebar. I just realized that my left thumb is
\completely/ unused!
--Bruce
------------------------------
Date: 19 July 1981 20:38-EDT
From: Marvin Minsky <MINSKY at MIT-MC>
Subject: visionary terminals
To: WORKS at MIT-MC
The general question of sneezing, etc., is interesting, and I wonder
if there is a nice theory of this: many interaction-devices separate
"pointing" and "doing". One positions a mouse and then presses an
action-button. This makes things clear to the computer, and protects
us from using signals than can be accidental. One does not often type
"DELETE *.*" as a side-effect of a sneeze.
In my vision, the AI sensing system gets better and better at telling
what you intend. In the first decade, I suppose, we'd be lucky to get
it reliably to tell where you're pointing, or what simple verbal
command you said. In another generation, it would be able to tell
when you're talking to IT, rather than someone else who just came in.
("What're you doing?" "Oh, just deleting everyone's files" -- meant
sarcastically, of course, but obeyed by the clever system.) As we
progress, the systems should grow better at telling what you really
want, and being sensible about which such intentions are plausible.
Of course, I don't believe that programming will become a casual,
natural language activity, because I don't think natural language has
adequate ways to describe an advanced programmer's intentions. (But
perhaps in a couple of generations a new order of procedural
expressiveness will indeed creep into everyday life!)
------------------------------
Date: 19 July 1981 1849-EDT (Sunday)
From: Jordan.Nash at CMU-10A
To: works at mit-ai
Subject: Terminal input devices
Message-Id: <19Jul81 184908 JN70@CMU-10A>
If we are willing to disregard cost for the moment, why not
consider pupil tracking technology as an input device. One could
simply look at the desired operation displayed on the screen and
perhaps confirm its selection by pushing a button. This certainly
eliminates the hand coordination needed for mouse input and the
sticky screen and physical exertion of the touch panel. Having
been attatched to a pupil tracking device, I realize that current
design is uncomfortable for the trackee, but I don't know enough
about the technology to throw out the idea.
Any thoughts?
/Jordan Nash
------------------------------
Date: 20 July 1981 0357-EDT (Monday)
From: Lars.Ericson at CMU-10A
To: WorkS at mit-ai
Subject: Soft Keyboards
Message-Id: <20Jul81 035716 LE60@CMU-10A>
Has anyone ever tried to build LED's right into the keytops?
This idea has always intrigued me, though it would make for
a rather expensive keyboard. Then when one wanted a new
character set, one would simply download a new set of keytop
images to the keyboard. No messy paper stickons; invent new
symbols; who knows what possibilities?
No, I do not consider a video display with a touch sensing
pad over it to be a reasonable equivalent to this.
------------------------------
End of Collected Responses on Terminal Input Devices
****************************************************
Subject: terminals versus comp centers
∂21-Jul-81 0814 Hank Walker at CMU-10A (C410DW60) terminals versus comp centers
Date: 20 July 1981 1815-EDT (Monday)
From: Hank Walker at CMU-10A (C410DW60)
To: apollo at MIT-AI
Gordon Bell has pointed out that disk drives and fancy printers
are about the only things left that have economy of scale. You
might as well chop everything else into little pieces, it makes
the incremental cost smaller.
As almost everyone on this list surely knows, comp center people
frequently tend to be power-mad, bureaurocratic, etc. Given the
choice, would you rather use the comp center or the CS department
machines?
When computing is relatively free, all arguments about wasted
cycles are bogus. You should think of your computer like your
car. Are you worried that you car is sitting idle all day
while you are at school or work? I'd think that you'd be
plenty worried if it wasn't. Are you worried that it isn't
being used at night? No. Same goes for computers.
To do fancy graphics, you need a lot of local processing due to
bandwidth. Once you do that, adding general purpose computing
isn't all that hard or expensive. If the graphics is done by a
general-purpose CPU, a la Alto, then the cost is essentially
zero.
Subject: Collected responses on terminal input devices
∂21-Jul-81 0922 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected responses on terminal input devices
Date: 21 Jul 1981 09:00-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
------------------------------
Date: 20 Jul 1981 12:09 PDT
From: Kimball at PARC-MAXC
Subject: Terminal Input Devices
In-reply-to: WorkS-REQUEST's message of 20 Jul 1981 08:00-EDT
To: WorkS at MIT-AI, ALBrown
Speaking of soft keyboards, I'm surprised no one has mentioned
an old idea that has been kicking around 5 or 10 years: an image
of the keytops can be generated on the display and then reflected
off a half silvered mirror that is mounted over the keyboard.
The user can see the keys (even when his hands are over them!)
with whatever labelling he desires, switched at electronic speed.
Furthermore the geometry is such that the user doesn't have to be
exactly "on axis" to see the desired image.
Of course, there are some drawbacks, but none of them seem to be
showstoppers:
1) a lot of expensive resources (e.g. bitmapped display &
memory) are given up to support the keyboard image. Also
the image on the screen surface itself is upside down;
2) the glass "shield" over the keyboard sounds awkward;
3) I wonder whether screen curvature, raster blooming, and
the like would make it hard for the keytop images to be
precisely aligned with the physical keyboard.
Ralph Kimball
P.S. Allen Brown tells me that this concept was explored
by someone in IBM on behalf of J. C. R. Licklider
(Licklider @ MIT-XX). Forgive me if this is a garbled
pointer.
------------------------------
Date: 20 Jul 1981 1319-EDT
From: Bob Hyman <HYMAN at DEC-MARLBORO>
To: SHRAGE at WHARTON-10, works at MIT-AI
Subject: Re: Interchangable keyboards
In-reply-to: Message from SHRAGE at WHARTON-10 (Jeffrey Shrager)
of 18-Jul-81 0641-EDT
At an NCC a while ago, I saw a terminal with a dynamically
lableable keyboard. The keys were arranged in a 10 x 50 matrix,
and had transparent tops. There was a mechanical (air-driven,
I believe) sheet feeder that could slide any one of about 10
different layouts under the key matrix. The particular layout
was selected by function keys off to one side, and it took about
1/10 sec. to switch, accompanied by some hissing and clunking.
It was not an entirely unworkable arrangement.
------------------------------
Date: 20 Jul 1981 1218-PDT
From: Steve Klein <SKLEIN at USC-ISIB>
Subject: QWERTY space bar
To: WorkS at MIT-AI
If the RETURN key is in the wrong place and the full-length
SPACE bar is a waste, why not split the SPACE bar and use the
left thumb for RETURN? One would think this would not cause
too much trauma either for manufacturers or users.
------------------------------
Date: 21 Jul 1981 00:39:45-PDT
From: decvax!duke!unc!smb at Berkeley
To: WorkS at MIT-AI
Subject: keyboard tracking system
Cc: duke!shg@Berkeley
This note was sent to me; I thought I'd pass it on
>From duke!shg Mon Jul 20 09:34:50 1981
Date: Mon Jul 20 09:33:20 1981
I saw your note about a keyboard tracking system. It
seems to me that the most convenient position for a cursor
control setup is just below the space bar on the keyboard.
A small trackball or joystick modified (or even a two-
dimensional slide switch) could be easily manipulated by
either thumb without moving the fingers from the keyboard.
I find that I always use my right thumb for spacing,
thus I guess with a little practice I could use my left
thumb for cursor control EVEN WHILE TYPING.
------------------------------
Date: 20 Jul 1981 0838-PDT
From: WMartin at Office-3 (Will Martin)
Subject: Keyboards
To: works at MIT-AI
Message-ID: <[OFFICE-3]20-Jul-81 08:38:32.WMARTIN>
Keyboards: There was a LONG series of discussions on Human-Nets
some time back about Dvorak keyboards. If there are people on
this list who weren't exposed to that, maybe somebody with an MIT
account could run an editor through the HN archives and come up
with a consolidated file for FTPing of that exchange. Would be
appropriate as the list seems to now be covering alternatives to
the standard keyboard, and Dvorak has lots of supporting data
which was outlined in that discussion.
[ A transcript of the HUMAN-NETS discussion on keyboards is
available in the file DUFFEY;WORKS KEYBRD on MIT-AI. -- RDD ]
------------------------------
Date: 21 July 1981 02:12-EDT
From: Marvin Minsky <MINSKY at MIT-AI>
Sender: MINSK0 at MIT-AI
Subject: pointing devices
To: MINSKY at MIT-AI, WORKS at MIT-AI, norman at NPRDC
I agree with Donald Norman about re-examining keyboards. I
wasn't concerned with keeping hands on keyboard, because I
once learned some American Sign Language (ASL) and saw that
sign-language works quite well and could be quite fast --
provided the intelligent observing machine can keep up. One
learns a large lexicon of special words and symbols in ASL
and, when these fail one uses "finger-spelling". The latter
is lots slower than expert typing, to be sure. But this is
because one has to reconfigure the whole hand for each letter;
the vision machine could sense smaller finger changes than a
person could, I think. Then we could adopt Norman's idea
of using bidirectional finger motions, and little "chords",
etc. In the end it should be faster than typing.
Gloves and rings and things might do, but I think AI will get
around to making good seeing machines eventually, and they'll
do so many things that they'll be cheap. In the end, there
will be two or three of them inside the average typewriter,
just watching for paper jams and ribbon problems. After a
while, people will find that they don't need many of the
machines that the vision boxes were made to keep an eye on.
------------------------------
Date: 20 July 1981 1222-EDT (Monday)
From: Hans Moravec at CMU-10A (R110HM60)
To: WorkS at mit-ai
Subject: Gloves
Along with the keyboard gloves you get a head-mounted binocular
display, as in the old Utah 3D system. Now you can not only
move your head from side to side to reveal obscured pages,
but can walk around your workspace and view it from behind or
underneath. If you're into such, the entire workspace can be
mapped onto the surface of your real desk, and there can be
simulated piles of paper that look like the real thing! To
focus your attention on one, just move your head closer to it.
If the head mounted display carries outward looking cameras
that can track your fingers (and microphone and earphones),
you could pick up and shuffle the simulated paper. In the
long run all this stuff should be integrable into an
eyeglasses frame.
It needs some kind of intertial or other navigation system to
make sure it knows where your head is to generate the appro-
priate view. With a radio link to a communication system and
a shaving mirror it could be used as a videophone. Or a cheap
telepresence terminal. Or a syntha-presence unit; Imagine the
adventure display possible when you can walk around the scenes
in 3D (need a lot of crunch power for this, but much more
practical than some "holographic" methods suggested by Niven).
Better watch your icons, though!
------------------------------
Date: 20 Jul 1981 (Monday) 1804-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: In response to "gloves"
To: works at MIT-AI
It was suggested to my by Saul Levy of Bell Telephone Labs, (as
not to implicate myself) to use Teflon Boots that someone puts
their feet into, as not to have to remove one's hands from the
keyboard when typing. I leave this as a comment nothing more.
Hank
------------------------------
Date: 20 July 1981 1056-EDT
From: David Smith at CMU-10A
Subject: Pointing devices
To: WorkS @ mit-ai
In the summer of '78, I saw a demo at SRI of a device which
could tell where your eyeballs were pointed. It used internal
reflections in the lens. People were writing their names with
it. The writing was rather jerky, because the eyeballs move in
saccades. If your work station had one of those, plus a speech
(word) recognizer, you wouldn't have to remove your hands from
the keyboard to designate an icon. Lacking a speech recognizer,
you could type escape-footpedal-foo, but that lacks class.
------------------------------
Date: 20 Jul 1981 1351-PDT
From: Kelley at OFFICE
Subject: The Back Split Twist Keyboard
To: works at MIT-MC
Take the Maltron contoured keyboard. Chop it in half down the
middle. Put mice wheels under each half. Pick the portion of
the desktop you are viewing on the screen with one half. Pick
entities on the screen with the other half. No need for your
hands to leave the keyboard. Engineer a little to keep the
keyboard stationary while you type.
Now. Take a flat display screen that fills one whole surface
of a box about the size of the Whole Earth Catalog. Put your
processor in the box. On the back, place each half of the
keyboard twisted so you are holding the book while you type.
Control wheels / track ball on the side with the thumb / palm
of your hand. Control your dynabook with your back split
twist keyboard while you walk the earth.
-- kirk
------------------------------
Date: 20 Jul 1981 (Monday) 1935-EST
From: STECKEL at HARV-10
Subject: recommended reading
To: WorkS at MIT-AI
Seeing the flames and flak fly freely the last few weeks, I
would strongly recommend all participants to read the issue
of the ACM Computing Surveys Vol 13 no. 1 of March, 1981.
It addresses "human factors in computing". Especially of
interest are the article on editors and Beau Sheil's
article.
Aside, I would suggest that the ideal "terminal" look like
a pad of paper (flat screen display), with a keyboard on the
lower 1/3 or so...
g steckel
------------------------------
End of collected responses on terminal input devices
****************************************************
Subject: WorkS problems
∂21-Jul-81 1105 DREIFU at WHARTON-10 (Henry Dreifus) WorkS problems
Date: 21 Jul 1981 (Tuesday) 0950-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: WorkS at MIT-AI
WorkS has now grown to include roughly 750 people on 50 sites
across the ARPAnet. The number of topics being discussed at
any one time has increased from 1-2 to 4-5. Somewhere between
12-15 messages are submitted to the list each day. Each day's
submissions comprise approximately 15,000 characters of material.
The result is that WorkS is beginning to suffer from severe
problems. Problems which many people have begun to note.
It takes roughly 30 minutes (real time) of processing by the
mail server to redistribute one, 1000 character to everyone on
the WorkS mailing list. The amount of time required depends on
several factors. The most important factor is simply the total
number of individual message transmissions that the mail server
must do.
For example, consider the difference between distributing one
20,000 character message and 10 2,000 character messages to
WorkS. The 20,000 character message will require around 100
minutes (real time) of processing by the mail server. The 10
2,000 character messages will require 300 minutes (real time)
of processing by the mail server. Here you see the advantage
in redistributing the messages oriented around a single topic
as a collection of messages rather than as individual messages.
However, that expedient is proving inadequate to deal with
WorkS problems.
This means in all probability that WorkS will have to become
another digest mailing list. Over the next few days we'll
explain what this change entails. In the meantime we will
continue with redistributing the incoming messages in topical
collections where appropriate.
Comments/opinions/questions to WorkS-REQUEST at MIT-AI.
Hank Dreifus
Subject: Realtime proofreaders
∂21-Jul-81 1022 Robert Elton Maas <REM at MIT-MC> Realtime proofreaders
Date: 21 July 1981 09:25-EDT
From: Robert Elton Maas <REM at MIT-MC>
To: SHRAGE at WHARTON-10
cc: works at MIT-AI, ellen at MIT-XX
The advantage of automatic fixups is that you can spend your time
proofreading for deep stuff instead of proofreading for trivial
spelling errors and the like. (This is the general thing about
automation, you let the computer or other machine do the trivial
stuff so you can have more time to do a good job with the deep
stuff. FFM loosely quotes somebody named "Andre Gide", who said
"This has all been said before, but since no one was listening it
bears repeating.")
The advantage of realtime fixups, or at least flags you can
confirm later, is that the typist can detect whether something
heesh noticed as a mistake was also noticed by the computer
instead of wondering for the next hour if the post-processor
will find it; if the computer flagged it, then the typist can
safely ignore it now, even forget it, because heesh will be
reminded of it later when making a big confirm-pass thru the
document.
The problem with TWENEX is its method of flagging errors in
realtime is obtrusive. It goes ahead and makes a mess, instead
of just brightening or boxing the offending misspelled word and
letting the user move the mouse back there later to fix the word.
(Of course this is because it was designed to work on TTYs and
Decwriters, not ALTOs and other graphics-mode displays with
massive display-computing power and mouse.) Perhaps somebody
with experience on Xerox-Smalltalk on Dorado could comment on
how Xerox-Smalltalk handles errors when manually typing in
commands (instead of using the mouse to select commands from
a menu). I seem to recall you type commands into a window
and can edit them to your heart's content, then when you hit
the activation button on the mouse they are parsed and any
syntactic error is flagged, and you can edit again and again
until the parser accepts it.
Right?
Subject: File Backup
∂23-Jul-81 0031 Joe.Newcomer at CMU-10A File Backup
Date: 22 July 1981 1649-EDT (Wednesday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
In-Reply-To: <[OFFICE-3]20-Jul-81 08:38:32.WMARTIN>
The Spice project plans to treat the local disk as a cache for
the central file system. Thus, primary backup is handled by
the same staff which backs up all our other systems. Local
disks will not have substantive amounts of private data which
is not replicated on the CFS.
In the case of workstations not on a network, if we abandon
such archaic ideas as single-task workstations, files without
timestamps, and similar absurdities, and produce some reasonably
intelligent software, a background task which does hourly, daily,
or as-needed backup to a floppy disk or other medium such as
streaming tape, occasionally prompting the use to insert a new
disk or tape, and which handles the grubby details of how to do
file retrieval in case a file restoration is necessary seems the
obvious simple solution. As I am currently thinking about having
a personal 68000-based system at home, which will not be on a net-
work, and cannot use CMU's machines for backup, this is one of the
first pieces of software I would build. My plans are to simply
assign ascending serial numbers to the floppies, and keep a file
(which is naturally backed up) which is a migration archive file
[CMU-10A users will recognize this as MIGRAT.DIR...]. Since all
REAL computers (not toy computers, no matter how powerful) have
date-time stamps which can go on files, the software architecture
is reasonably obvious.
Those ridiculous systems in which one can save or restore the
entire disk, but not do incremental save or restore, are not
worth talking about. I certainly don't want to reset my
entire disk to yesterday afternoon just because the system or
I accidently damaged one file.
More sophisticated applications, including large databases, need
more sophisticated incremental backup procedures. But these are
ALL OBVIOUS and can be ALL AUTOMATED. Using "clerical people"
or "professional people" means we've forgotten the best drudge of
history: the computer itself. The overhead on anyone to write a
serial number on an existing disk or streaming tape and insert a
fresh one is so small as to be unnoticeable. (Of course, I would
never consider the problem of "tying up the floppy drive" while
doing backup; floppies are not reasonable as secondary storage for
serious applications; they are far too small and slow compared to
even the current processors they are mated with. I consider a 10Mb
disk as small, but marginally acceptable, on a personal workstation.
24Mb is acceptable, 100Mb is reasonable. Floppies are at best a
cheap backup medium, not to be used for serious storage. I have
a small personal database which already exceeds 1Mb).
joe
Subject: Collected responses on terminal input devices
∂23-Jul-81 0228 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected responses on terminal input devices
Date: 23 July 1981 02:00-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at AI
------------------------------
Date: 21-Jul-81 14:55:07 PDT (Tuesday)
From: Hamilton.ES at PARC-MAXC
Subject: Re: Terminal Input Devices
Another problem with the idea of reflecting images of keycaps onto
the top of the keys is that it prevents the use of a detachable
keyboard. Some human factors expert at NCC spent a lot of time
ranting and raving about how important detachable keyboards are.
Also, the natural touch-typing position would mean that (1) the
home-row images would be invisible because they would appear
on my next-to-last finger bones, which are angled back toward
the screen, and (2) for most keys below the home row, the image
would appear on my fingers or hands at such a distance above
the keyboard as to make the association with an individual key
rather difficult. This could even become a racial issue(!),
since presumably black people's hands don't function nearly
as well as projection screens.
All in all, if you really want to look at the keys, the key sides
are a lot more visible than the key tops, unless you're some kind
of two-fingered wonder at the keyboard.
I don't think anyone has mentioned the idea of burying a small,
high-density CRT inside the keyboard and then using fiberoptics
to route the appropriate portion of the image to each keycap.
--Bruce
------------------------------
Date: 22 Jul 1981 0941-EDT
From: Eric K. Olson <OLSON at DEC-MARLBORO>
Subject: Terminal Input Devices
It seems to me that the position of the operator's head is very
important in a scheme to reflect the key markings off a half-
silvered mirror. I have always hated things with half-silvered
mirrors anyway, because head positioning is so critical. Also,
it eliminates the possibility of a removable keyboard.
On another tack, I was discussing some of these schemes (boots,
gloves, rings, LCD keytops, etc.) with a friend here at DEC and
he was repulsed by them. He wasn't even interested in foot pedals.
Then again he has always worked for DEC (since leaving WPI), and
neither DEC nor WPI are exactly at the forefront of these ideas.
It suprises me that no-one has mentioned the possibility (seriously)
of mounting the keyboard on a (large) mouse. Mice don't have to move
a great deal to scroll the entire screen, and four mounted as the
feet of a removable keyboard could work nicely. They would need a
sticky surface and would have to require more umpf to push them (in
order to avoid false readings), but I think the idea is feasible.
For those of you in love with chord keyboards, you could mount a
mouse under one even easier.
If you think this is entirely ludicrous, I cast my second vote for
a trackball near the left thumb (perhaps cutting the spacebar short).
My VT100 does not insist that a distort my hand too much to hit the
return key (it is a selectric arrangement), and I would rather be
cursory with my left thumb. However, as my WPI/DEC friend points
out, it can be hard to use: he has a broken left thumb.
------------------------------
Date: 22 July 1981 01:41-EDT
From: Frank J. Wancho <FJW at MIT-MC>
Subject: Keyboard Augmentation
Someday, I will actually try to implement this: maybe three
footpedals, one for Shift, one for Control, and one for Meta
(Edit). I have had a sore left wrist for three months now,
and am just beginning to realize just how much I use and
contort that hand/wrist to use those keys. Footpedals would
certainly go along way to aleviate that strain.... maybe not
just three...
--Frank
------------------------------
Date: 22 July 1981 1751-EDT (Wednesday)
From: Joe.Newcomer at CMU-10A
Subject: Finger distortion
I find the backspace and escape keys even more awkwardly placed
than CR. I usually use ↑H in preference to Rubout or Backspace
because the finger travel is shorter and faster, but not all
systems treat ↑H, Backspace (which is usually ↑H but sometimes
sent as rubout, depending on your terminal) and Rubout
identically.
joe
- - - - Begin forwarded message - - - -
Date: 16 Jul 1981 (Thursday) 1503-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
Subject: Interchangable keyboards
To: works at MIT-AI
Via: MIT-AI; 18 Jul 1981 0639-EDT
I once saw design specs for a keyboard in which the keytops were
little LCD displays and were, of course, under computer control.
The types of things I can imagine doing with such a device are
virtually unlimited: Emacsify the keyboard for ↑X or ESC (Sorry,
Fineify), show keywords like various Basic systems, swap your
keyboard to APL mode with the screen, etc, etc. Does anyone
actually produce such a device?
- - - - End forwarded message - - - -
------------------------------
Date: 21 Jul 1981 21:57:41-PDT
From: ihnss!mhtsa!harpo!chico!esquire!psl at Berkeley
Subject: Talking Workstations
Have there been any measurements of the relative `work' involved
in:
a) typing "s/foo/"
b) finding a key labeled "ENTER", hitting it, typing
"foo", finding a key labeled "SEARCH" and hitting it
c) saying "SEARCH!" then saying "EFF OH OH (pause)" ?
------------------------------
Date: 22 Jul 1981 18:10 PDT
From: Kosower at PARC-MAXC
Subject: Re: mice,balls,touch-plates,pens.
In-reply-to: MINSKY's message of 18 July 1981 (Saturday) 01:20-EDT
Better yet, we could construct a box that "listens" to the
user's brainwaves (or brainstorms, as the case may be...) and
figures out from that what the user wants to do, and does it.
That way, the user would be completely spared the tedious task of
pointing. And by using a little more AI, we could construct a box
that would figure out what needed to be done (edit reports, write
programs, answer mail, etc.) and would do it without any user
intervention at all. That way, we could get rid of "reactionary"
old terminals and perhaps with the user to boot!
David A. Kosower
------------------------------
Date: 21 Jul 1981 21:56:01-PDT
From: ihnss!mhtsa!harpo!chico!esquire!psl at Berkeley
How can you call that a workstation without holocamera & odorama?
------------------------------
End of collected responses on terminal input devices
****************************************************
Subject: More on configuration
∂23-Jul-81 2309 BHYDE at BBNG More on configuration
Date: 23 Jul 1981 1116-EDT
From: BHYDE at BBNG
To: WorkS at MIT-AI
Message-ID: <[BBNG]23-Jul-81 11:16:04.BHYDE>
Let me repeat some of the phrases in the replies to my query on
configuration.
From Steve Crockers message;
"the cost of the separate packaging is less than the cost
of multiplexing several users onto ... larger ... machine."
"things do remain centralized, an properly so: file servers,
high quality printers, long distance communications, ...
maintenance ... system development ( hardware and software )"
"classical time-sharing ... forces overloading of the machine
... this can be seen as miss management... with computation
tied to terminals it becomes ... impossible to add people
without adding capacity."
"transition from small task fitting on a work station to a
larger task ... will be ... painful."
From Hank Walkers message;
"disk drives fancy printers are about only things left with
economy scale ... might as well chop everything else into
little pieces, it makes the incremental cost smaller."
attributed to Gordon Bell
"center people frequently ... power-mad, bureaurocratic."
"are you worried about you car sitting idle?"
"fancy graphics needs a lot of local processing .. (then the
cost of) ... adding general purpose computing ...(is) ..
essentially zero."
Forgive me for the paraphrasing and quotation out of context.
I find quite convincing the point that baseline services; communi-
cations, graphics processing, and packaging make the marginal cost
of a substantial piece of computing power in the office trivial.
No ones seems to argue for the demise of the computing center, I
had expected people to argue it would be replaced; on the low end
by work stations and on the high end by external service firms.
People seem to believe that central facilities, file servers etc.
will remain within the organization.
As an aside the comment about cost of multiplexing into the central
facility seems odd considering the huge increase in cost of communi-
cations that local networks imply verses front ends. Any one want
to argue the other side of that one? No one has explained to me
yet why the hugh bandwidth is a good thing in the local computing
environment?
I have believed that the leverage available in purchasing larger
machines was very substantial. If I build out of a fast expensive
technology I get a power of ten improvement in my cycles for a
linear increase in my cost. If I build out of many processors
I get a linear increase in power for a linear increase in cost.
Have I been stupid and mislead?
If this is true than, disks, fancy printers, communications, and
fancy processors will go in the central facility. The work station
design will be aligned on a cost effective boundary one up from
that amount of power necessary for graphics, communications, and
work space management.
I find the comment about cars rich in metaphorical implications;
there are many people who believe that cars are a very poor piece
of social engineering. Do organizations have more capital tied
up in the parking lot than they do inside? Unsafe at any speed?
Ben Hyde
Subject: WorkS Software.
∂24-Jul-81 0011 DREIFU at WHARTON-10 (Henry Dreifus) WorkS Software.
Date: 23 Jul 1981 (Thursday) 1928-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: works at MIT-AI
Part-III
The Hardware is one thing, the software is the more lasting concept.
Will the future software change? Will we see more screen-formatting
packages, better user interfaces?
What about the programmer? Source level Debuggers, complete control
of the machine (micro-code all the way to the I/O slot which is
latched to the on/off switch)?
Screen this, and menu that.
Will there be standards for screen definitions? Not at all
unlike the Core←graphics←standard we are seeing now, thanks
to VanDam and Badler and company.
Will there be "drivers" for One-User software? Distributed
power, shared computing, the questions of Queuing processes
accross machines - across the country.
Local-vs-Long Distance networks. How does one effectively
integrate this? There are more machines out today than ever
before.
The above are just some thoughts/interesting topics to get
discussions going off over all of the innovations necessary for
PersComs.
Henry Dreifus
Subject: Collected responses on useable systems
∂24-Jul-81 0036 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected responses on useable systems
Date: 23 July 1981 04:17-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WORKS at MIT-AI
------------------------------
Date: 23 July 1981 16:29-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
Subject: mundane
To: Joe.Newcomer at CMU-10A
Joe Newcomer raises a very good point in his letter of July-22:
I find that I have less and less time to worry about,
say, how to make CR in EMACS behave like LF and how to stop
LF from behaving differently if the previous line started at
the left margin. I know what effect I want; I don't want to
know about 37 different variables, TECO FS-flags, and other
crap to get a simple change in behavior. This is a lot of
what is involved in getting really good personal workstations;
if I have to remember dozens of incantations to, say, set up
defaults when I boot, I'm not going to be very happy.
joe
=-=-=-=-=
Peter Keene (sp?) of MIT Sloan School has a nice way of describing
the sort of system behavior Joe is looking for: mundane.
If I am not a car wizard I want my car's behavior to be mundane.
I want my car to be boring, I don't want it doing interesing things
like losing wheels. Many car drivers also don't want to learn all
the exciting things that you can do with manual transmission, boring
old automatic transmissions are good enough to get where you are
going.
If I am not a phone wizard I want my phone to be mundane. I am
not particularly interested in the intimate details of the phone
billing system when I am complaining about a $7,000 phone bill,
I really wanted the phone company to do the boring old thing and
bill me my normal ammount.
I believe that most people will want their workstations to be
mundane. They probably won't want a 3 week training course to
learn all sorts of wizzy neat features. If it behaves mostly
like those boring old office equipment (typewriters, phones,
etc.) it will probably be enough. After all, most people will
be using the workstation as a tool to get their work (what they
find interesting enough to be paid for) done.
- Steven Gutfreund
------------------------------
Date: 23 July 1981 04:17-EDT
From: James M. Turner <JMTURN at MIT-AI>
Subject: Various subspecies
To: Joe.Newcomer at CMU-10A
Shade and Sweet water,
But designing systems who's most inexperienced user is it's
lowest common denominator severely limits what can be built in
to the language.
As an example, I am currently involved in moving Scribe
to the Lisp Machine (albeit, in a greatly changed appearence).
A decision that was made very early was that although the
DOCUMENT (the Scribe input file) requires no specialized
knowledge to write, extensions to the system itself require a
working understanding of Lisp, and the way Scribe works in this
version. The idea behind this was that if we tried to create
a "secretary extensible" environment, we would be sacrificing
efficiency (important in a package which is already dangerously
slow due to LISPM <-> PDP-10 I/O speed) and clarity of code for
the benefit of people who would probably not wish to change the
code anyway.
Besides, the typical supervisor doesn't want "low level"
personnel fooling with the code anyway. A friend who is
currently doing DE for DEC related the story to me of how her
supervisor had flamed when she had poked around the OS trying
to find out how to logout (it seems SOP was to hang up, which
she could not accept).
James
------------------------------
End of collected responses on useable systems
*********************************************
Subject: Sperry Univac workstation design group -- eyewitness testimony
∂25-Jul-81 0946 SHRAGE at WHARTON-10 (Jeffrey Shrager) Sperry Univac workstation design group -- eyewitness testimony
Date: 24 Jul 1981 (Friday) 1356-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
To: works at MIT-AI
I was invited to Sperry's Software Research group and had an
opportunity to speak with them and examine some of the work that
they are doing in workstations and in programmer's tools. They
are more concerned with the "programmer's workstation" than a
management workstation and thus are putting a lot of effort
into the language that controls the device. It is designed to
be modified by the user and has inboard multitasking and file
system, etc. Understand that this design is for a device to be
hung from a large central machine for program developement NOT
for execution of programs. Here is a short list of the things
that (I saw) that they were thinking about/working on:
1) Pascal debugging/programming aids. They have a really nice
design (and partial implementation) for a visual program stepper
that draws colored boxes around the program structure and then
highlights the lines as they are executed so that the programmer
can "see" the program in exectution. It (will) also display
the variables and structure nicely. I played with this and it
made it very very simple to visualize what a program was doing
(especially when you turn the speed up fast enough and can see
where the loops are crunching along). The final implementation
of this should be very nice. [Jim Gimple (formerly a Snobol
afficianado from Bell) is doing this work].
2) A high res/color PWB system with joystick and mouse. They are
spending a lot of time working on the "editor language" (which
is also the JCL and workstation control language) rather than
"cutsie" features to add to the user view. The file structure
is Unix based but they ALSO feel that unix's user view is a
total lose and are designing one of their own that, from what
I saw, will be much nicer. Again, their position is that this
will be used by programmers, not managers or secretaries and
they are giving the user power to change things (in a properly
controlled manner) at whim without too much work. Currently
they are having trouble with the Univac hardware research
people (it's too slow for them) but that should be resolved
soon. This project is under control of Marc Fogel and Ira
Ruben.
3) Help systems. Knoweldge based and natural language driven (if
you like) user aids for the station command language etc. They
have several NL and AI people very interested in user assitance.
I don't know how/if this relates to the workstation but it was
interesting none-the-less. This work was being done by Nathan
Relles and Norm Sondheimer (president of the ACL).
All of the above is managed in a very small group of very expert
people by Dick Wexelblat and for more info one can write to
Sperry Univac
Software Research
2G3 Bluebell, Penna.
19424
They are going to have an Apollo and/or a couple of Perqs soon.
-- Jeff
Subject: Sperry Univac workstation design group -- eyewitness testimony
∂25-Jul-81 0946 SHRAGE at WHARTON-10 (Jeffrey Shrager) Sperry Univac wo
rkstation design group -- eyewitness testimony
Date: 24 Jul 1981 (Friday) 1356-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
To: works at MIT-AI
I was invited to Sperry's Software Research group and had an
opportunity to speak with them and examine some of the work that
they are doing in workstations and in programmer's tools. They
are more concerned with the "programmer's workstation" than a
management workstation and thus are putting a lot of effort
into the language that controls the device. It is designed to
be modified by the user and has inboard multitasking and file
system, etc. Understand that this design is for a device to be
hung from a large central machine for program developement NOT
for execution of programs. Here is a short list of the things
that (I saw) that they were thinking about/working on:
1) Pascal debugging/programming aids. They have a really nice
design (and partial implementation) for a visual program stepper
that draws colored boxes around the program structure and then
highlights the lines as they are executed so that the programmer
can "see" the program in exectution. It (will) also display
the variables and structure nicely. I played with this and it
made it very very simple to visualize what a program was doing
(especially when you turn the speed up fast enough and can see
where the loops are crunching along). The final implementation
of this should be very nice. [Jim Gimple (formerly a Snobol
afficianado from Bell) is doing this work].
2) A high res/color PWB system with joystick and mouse. They are
spending a lot of time working on the "editor language" (which
is also the JCL and workstation control language) rather than
"cutsie" features to add to the user view. The file structure
is Unix based but they ALSO feel that unix's user view is a
total lose and are designing one of their own that, from what
I saw, will be much nicer. Again, their position is that this
will be used by programmers, not managers or secretaries and
they are giving the user power to change things (in a properly
controlled manner) at whim without too much work. Currently
they are having trouble with the Univac hardware research
people (it's too slow for them) but that should be resolved
soon. This project is under control of Marc Fogel and Ira
Ruben.
3) Help systems. Knoweldge based and natural language driven (if
you like) user aids for the station command language etc. They
have several NL and AI people very interested in user assitance.
I don't know how/if this relates to the workstation but it was
interesting none-the-less. This work was being done by Nathan
Relles and Norm Sondheimer (president of the ACL).
All of the above is managed in a very small group of very expert
people by Dick Wexelblat and for more info one can write to
Sperry Univac
Software Research
2G3 Bluebell, Penna.
19424
They are going to have an Apollo and/or a couple of Perqs soon.
-- Jeff
∂26-Jul-81 2028 AVB Xerox announcement on Dolphin/1100
To: "@SUN.DIS[P,DOC]" at SU-AI
Date: 22 Jul 1981 1736-PDT
From: RINDFLEISCH@SUMEX-AIM
Subject: INFORMATION RE INTERLISP DOLPHINS
Ed Feigenbaum received the following message from Mr. R.E. Bomeisler,
Marketing Manager for Xerox EOS, in response to repeated requests for
more information about Dolphins necessary for planning acquisitions.
Since others may be in the same situation, Ed wants to pass the
information along to other computer scientists. You may forward
it if you wish.
Tom R.
*********************************************
7/16/81
"In our telephone discussion, Ed, you indicated that Xerox
was not providing you and potential users with enough information
to assist you in designing your networks and planning for future
growth. I would like to apprise you of the steps we have taken
at XEOS to fill the information gap.
Marcel Pahlavan is the program manager and is the focal
point for responding to customer inquiries on interface and other
technical matters. On August 1, Terry Haney will join the staff
to provide hardware expertise. An Interlisp software expert is
being actively recruited. In addition, Pahlavan can call on other
system experts within XEOS to solve specific customer problems.
With regard to 3M bps Ethernet networks, the 1100 system
includes the hardware necessary for connection. In addition,
XEOS will make available the hardware necessary to connect the
DEC Unibus. This includes the DEC Unibus Ethernet Interface
Board, Transceiver, Terminator and Connector. This hardware
enables connection to 3M bps Ethernet on the DEC PDP-11 family
aswell as the DEC 2020 and the VAX family. To connect the
DEC 2040, 2050, and 2060 to 3M bps Ethernet will require either
development of a Massbus Ethernet Interface Board or a PDP-11
front end interface. When either of these is developed within
the ARPA-sponsored research community, XEOS will facilitate
distribution.
XEOS is a systems organization with the skills to develop
special hardware or software. It is expected that we will be
called upon to modify the 1100 hardware or software to meet
special customer requirements.
With regard to DEC hardware/software, there exists within
the ARPA research community a number of special systems. Many
of these exist on your own campus. As we become familiar with
thesesystems, XEOS will serve as a facilitator and will make
certain that potential 1100 users are familiar with interface
software that exists or is under development. To the best of
our knowledge, the following systems have been or are being
connected to the 3M bps Ethernet: KI-10/TENEX, KL-10/TENEX,
2020/TOPS-20, 2050/2060/TOPS-20, and VAX/UNIX. XEOS will
facilitate distribution of the Stanford-modified PUP software.
As you know, this software runs under TENEX and TOPS-20 and
enables DEC KA-10, KI-10, KL-10, and DEC 2020 to act as file
server to the 1100.
The dissemination and distribution of information would
be greatly enhanced by formation of an 1100 users group. XEOS
is prepared to assist in the organization of such a group.
XEOS plans to make available the necessary hardware and
software to connect the 1100 system to the 10 M bps Ethernet,
thus providing access to the Xerox 8000 Network System. We
are also investigating the feasibility of an internet gateway.
With regard to 1100/Interlisp performance, continual
improvements are being made in the code. The system is five
times faster than it was a year ago and significant further
improvement is expected.
Since the 1100 is a powerful, flexible machine, it can
be expanded in a number of ways: physical memory from 576K
words (1.15 M Bytes) to 768K words (1.54 M Bytes), virtual
address space from 4M to 16M words, and increased local disk
storage capacity. Furthermore, there is sufficient cabinet
space to add special functions that might be needed by certain
customers: floating point arithmetic, color display interface,
image processing, and other special logic, etc. XEOS is inves-
tigating the feasibility of adding to the 1100 system: color
display, low cost bit map display, large capacity file server,
and 5700 electronic printing system. The architecture, I/O
structure, and bandwidth of the 1100 make it the ideal machine
for dedicated applications in the research and scientific
environment.
In addition to Interlisp, XEOS is planning to implement
Smalltalk on the 1100. The schedule is yet to be determined.
As a key ingredient of the overall 1100 program, it is
planned to release a version of Interlisp on the Star processor
after January 1, 1983. This will provide Interlisp to future
users on a very cost-effective basis.
I trust, Ed, that this information will enable you and
others to plan system expansion."
-----
Subject: "mundane" systems
∂26-Jul-81 1553 Jan Walker <JWALKER at BBNA> ''mundane'' systems
Date: Saturday, 25 July 1981 15:59-EDT
From: Jan Walker <JWALKER at BBNA>
To: WorkS at AI
I have to voice my strong support of Joe in his message against
"mundane" systems. The original message advocating mundane
systems used an analogy of a car -- you choose a boring automatic
because you don't care what wonderful things you might be able to
do with a standard transmission. Let's point out a few things
that make this analogy somewhat less applicable to the current
case (system/software design).
Notice that with the kind of technology people are accustomed to,
once you choose one (automatic), you can't have the other
(standard). (This can lead people into defending their choices
with more reasons than they originally had for making the choice.
Some psychologists talk about related phenomena under "cognitive
dissonance".) With the kind of technology we use, you can either
follow the same design philosophy -- make things in a limited
number of flavors and make people choose -- or you can design to
support redesign by the purchaser. Surely with the flexibility
of computers behind us, we can do at least as well as the kludge
in the car that chooses 4, 6, or 8 cylinders depending on load,
mileage goals, or whatever.
People don't like the illusion of choice nearly as much as they
like having the choice. The reason that so far we don't find
ordinary people looking for software modifications is that they
don't expect to be able to have them. (The old technology of
course has molded people's expectations about the new one.)
While I am on the car analogy... I hear a lot about providing
systems for people who want to be able to use a computer without
any training or practice. How many people do you know who wanted
to just jump in and drive a car without any training or practice?
(Not many!) Why do you suppose that difference exists? Consider
that a car has one primary purpose -- transportation. They all
have standard components and operating procedures. Even people
who have never driven know a lot about cars, for example, that
they have a little slot where you put a key and turn it in order
to start the engine. The point is that cars are simpler in
purpose and operation than computers, yet people don't expect to
just hop in and drive away until they know from cars. Maybe the
real lessons in this analogy come from considering training,
learning, and transfer issues.
The ideal way to provide software is to offer something that a
new user who knows about the application of the software (for
example, editing, drawing) can start using it with the help of a
good summary and maybe 15 minutes of explanation. The next
hurdle to pass is in discovering that things can in fact be
changed. A well-designed and documented program helps you make
this discovery and then provides good support tools to help you
find out what it is possible to change and how best to do it.
Jan
(JWalker@BBNA)
Subject: re: REM' s remarks on Global configurations
∂29-Jul-81 0907 Farrell at PARC-MAXC re: REM' s remarks on Global configurations
Date: 27 Jul 1981 11:47 PDT
From: Farrell at PARC-MAXC
To: REM at MIT-MC
cc: WorkS at MIT-AI, Farrell
In places, you simply misunderstood / misstated Bruce Hamilton's
position; in others, your positions are new (and interesting).
Corrections/clarifications:
Bruce demanded 56 Kbaud, not Mbaud. The 3 orders of magnitude
easily cross the frontier of available technology.
There are a number of "centralized" services besides
archiving/library: printing, mail distribution, gateways to other
systems & nets, to name 3. Note also that file storage is a com-
munication mechanism as much as a receptacle -- it is easier (&
more efficient) to store a large object in a commonly accessible
container or two, & pass a pointer, than to ensure direct transfer
from the source to each destination.
Your framework of workstation & centralized facilities is impoverished
(and I believe not justified by Hamilton's discussion): there is no
requirement that facilities be centralized; in particular, there are
good reasons for distributing different services (functions) onto
different servers (machines), and for replicating and distributing
servers geographically (minimize communication, limit loss, provide
convenient user access). Even with most communications involving a
server on at least one end, this distribution still requires high
capacity in the underlying medium. When the net (or whatever) must
also support frequent reconfiguration, you may as well provide that
bandwidth to everyone, so you don't have to decide in advance which
ones are going to be servers.
Probably derived from your workstation/centralized facilities
dichotomy (and maybe a little from Bruce's remarks), I think
you put too much emphasis on network (i.e. communications medium)
failures, when server failures are more of a problem. I derive
this from my experience over 8 years now with two networks, ARPAnet
& 3mb Ethernet. In each, I can recall 1 occasion when I noticed
thenet was down -- that is, that NOBODY could use the net. (I
know the ARPAnet went down regularly for new releases of the IMP
software, and I've heard of outages on both which I didn't happen
to hit. . .) Contrast this to many occasions when I couldn't get
at MACSYMA, or the Datacomputer, or print on Clover, or wasn't
getting my mail, or . . . . Few of us are so single-minded that
we can't work around loss of a server (which needen't even deny
us the service -- e.g. redundant printing/file/mail servers).
Your super-automatic archive to file server has much to recommend
it; two possible drawbacks are that data on my local disk is less
accessible than anything that has hit the net or been stored in
a file server (clearly, holes that should be fixed; but while
they're there . . . ), and such a catholic approach may require
more resources than justified (I suspect workstation time and
file server space are more critical than communications
capacity).
Jerry Farrell
Subject: apollo s/w release 2.0
∂29-Jul-81 0941 Andy.VanDam at CMU-10A apollo s/w release 2.0
Date: 29 July 1981 1028-EDT (Wednesday)
From: Andy.VanDam at CMU-10A
To: works at mit-ai
CC: Andy.VanDam at CMU-10A
Message-Id: <29Jul81 102809 AD50@CMU-10A>
The second release of Apollo DOMAIN s/w happened as promised in
mid-July. Performance has improved greatly - cmd startup time
is (usually) instantaneous, cmds execute much faster (cp, for
example, is about 25% faster both for copying local-local and
over the network), and most known bufs have been fixed. Func-
tionality has also increase (although there's still plenty of
room for more increases...): there are a few new s/w tool cmds
(such as Unix-like sed, grep, macro processor), the display
manager (i.e., their full-screen editor) has cut, paste,
searches, and the user can access the display memory and
bit-mover.
In response to a query from the other week, yes, the Apollo
Users Workshop did take place at Brown on 21-22 June. Users
and potential users from: USAF Geophysics Lab, Bell Labs,
CaslTech, CCA, Computer Techniques, Cornell, Daniel Wagner,
AHarvard, IBM Cambridge, MIT, Mentor Graphics, Schlumberger
Well Services, UMass - Boston, UPenn, and Yale briefly
described what they are planning to do with their apollo's,
Dave Nelson and Bill Poduska talked in detail about the
company's plans for s/w releases and general growth, Kim
McCall from PARC-LRG talked about implementing Smalltalk
on an Apollo, and workshops were held about porting unix,
graphics, lisp, and tex.
The general reaction of the participants was that Apollo is
listening to its user community, which at present is primarily
CS R&D/academia. Apollo looks like it will be around for quite
some time, and will be emphasizing mktg for commericial world
(though they promise not to forget us CSers). Presently, the
h/w is quite solid, and most agree that the s/w is still about
a year away from being there.
Details of Apollo's plans discussed at the mtg are confidential.
Contact me for a list of participants (w/ phone, arpa addreesses)
that can be contacted for more direct info, or for a short (3
sentence) summary of what the participants said they'd be doing
with the Apollos.
Marc Brown
Subject: Mouse Guts
∂29-Jul-81 1023 Eric K. Olson <OLSON at DEC-MARLBORO> Mouse Guts
Date: 28 Jul 1981 0927-EDT
From: Eric K. Olson <OLSON at DEC-MARLBORO>
To: WorkS at MIT-AI
Message-ID: <MS"5(1631)"11747606017.5.545.5372 at DEC-MARLBORO>
Conglomeration of responses to "How does a mouse work?":
Currently, a mouse is a small box with a fairly large (1-2 cm
diam.) ball bearing captivated so a fraction of it lies outside
the bottom of the box. As the box is rolled around, two wheels
positioned perpendicular to one another pick off the rotational
motion of the ball in their plane only (they slip in all other
planes). Hence we get two rotational motions, one for each
component of the two-dimensional motion of the mouse.
The direction and (over time) speed of the rotation shafts are
measured by disks attached to the shafts encoded with a gray
code, and read either photoelectrically (via led and phototran-
sistor) or mechanically (via brushes). The grey code output
might look like 00 01 11 10 00 going one way and 00 10 11 01 00
going the other, so we can tell the difference in direction.
Some historical information about mice, according to Bill Barns:
The mouse as originally invented by Doug Engelbart and Bill
English and patented by them (rights assigned to their employer
at the time, Stanford Research Institute (now SRI International))
consists of two high precision potentiometers connected mechan-
ically to metal wheels with rather sharp edges, approximately 2
inches in diameter, and set at right angles to each other as close
as possible without touching. [This seems a kludgey way to get
this motion, because the pots would "pin" occasionally, even if
they were 20-or-more-turn.] The pots are mounted on a metal base
plate to which is attached a bracket. On the bracket there are
(in the original, and still popular configuration) three switches
which are triggered by buttons about 5/16 inch diameter [8 mm]
which rest upon spring metal fingers attached also to the bracket.
The bottom of the metal finger rests on the momentary-contact
actuator of the microswitch. This arrangement puts some "click"
into the feel. The switches typically are SPST with a common
ground so that for a three button mouse there are four wires for
the switches and one wire for the non-ground side of each pot - 6
total. The mouse wheel voltages are fed into an analog->digital
converter of about 10 to 12 bit resolution and at appropriate
times, some logic samples the digital value and does the
appropriate thing.
Engelbart lives on at Tymshare, and English went to Xerox PARC
and gave birth to Alto etc., (not sure if he's still there).
Bill estimates the invention of the mouse between 1962 and 1967,
and *guesses* 1963/4.
By the way, I got several warnings about suits, patents that I
musn't breach, etc, which I condense below:
Patents to SRI and Xerox apply to a number of features of the
design. The Englebart/English Patent is probably still in
force, and it covers both digital and analog mice. [I was
warned to check the patents before building my own. I really
don't think that building your own personal whatever falls
under patent laws (unless possibly if you sell it).]
Thanks to Jerry Farrell (Farrell at PARC-MAXC), Bill Barns
(Barns at OFFICE), Craig Everhart (Craig Everhart at CMU-10A),
and Steven Kirsck (SK at MIT-MC).
-----
Subject: Big AND Small
∂31-Jul-81 0459 Rivanciw at Darcom-HQ Big AND Small
Date: 30 Jul 81 8:37:19-EDT (Thu)
From: Rivanciw at Darcom-HQ
To: works at Mit-Ai
Via: Darcom-HQ; 30 Jul 81 8:49-EDT
In reading the debates pro and con on big systems and little
systems, where big systems are large mainframes and little
systems are personal workstations it seems that the best of
both worlds would be architectures for office automation that
encompass both. Let me illustrate how we have attempted to
incorporate both worlds in our OA plans.
DARCOM has a DEC 10 (DARCOM-KA) on the ARPANET which it uses
to provide electronic mail and other OA services to a broad
community of users throughout the command (the command is all
over this country). Access is via ARPANET. Advantages here
are that for a relatively inexpensive yearly charge a remotely
located single user can obtain OA service with a communications
capability as powerful as the ARPANET. This service is in such
demand that we cannot supply services in large enough quantities
(thus the DEC 10 will soon be replaced with a couple of 11/780s
to provide more services).
One level down (in computer size) DARCOM uses what it calls
LARGE CLUSTER machines. These are mini computers (DEC 11/70
size) which provide LOCAL OA services to 100-150 users. Long-
haul communications is accomplished via the RELAY computer
to the ARPANET (or dial-up communication channel to non-ARPA
computers). These Large Clusters are not hosts on the ARPANET.
The computer I am working on right now is one of these large
clusters. This message is routed to the RELAY computer which
routes it to the ARPANET for delivery.
The next level down SMALL CLUSTER. The small cluster is a
general purpose micro computer (like the ONYX or "C" Machine).
The Small Cluster services 8-30 users. It communicates with
the LARGE CLUSTER for large file storage and backup. Communi-
cations on the small cluster are handled via the large cluster
or the RELAY.
The lowest level is the personal workstation (one user). We
haven't gotten there yet in large scale implementation. Yes,
we have a lot of personal workstations around but have not
yet incorporated them into our large scale implementation
plans yet.
This architecture is used for economies of scale and incremental
investment on behalf of the user. For example, let me paint
a typical scenario of one of DARCOM's subordinate commands or
activities just entering into the world of office automation:
The Commander or somebody at the command wants to try office
automation. Now they are unsure of its benefits so they don't
want to spend mucho money. The buy a mailbox on our DARCOM-KA
(LARGE MAINFRAME). With this mailbox they can experiment with
all the OA tools.
After a short while they want 5 or 10 other people at
their command or activity to get mailboxes so that they can
communicate via electronic mail. They buy more mailboxes
on the large mainframe.
Then it is determined that office automation is good for the
command. They make large scale plans to provide OA services to
100, or 200, or 300, or how-ever-many prople. At this point the
economies of scale move towards the LARGE CLUSTER machine. With
a large cluster installed locally, the command is essentially
running their own OA.
But soon they find that more and more users are demanding service.
Enter the small cluster. As one division goes from one or two
users (who were getting OA services on the large cluster) to a
demand to provide services to 8 or 10 people in that particular
division, a micro computer is installed in the division to provide
those services (and offset the demand on the large cluster). An
example of this implementation is DARCOM Headquarters. We began
by buying accounts on the big DARCOM-KA (large mainframe). When
demand grew to 60 users we brought a large cluster into the
building. The number of users on the large cluster grew from 60
last Oct to 210 as of last week. We now have some 20 micros on
order. These micros will service 8-10 user each so we now supply
services to an additional 160-200 individuals. As folks move
off the large cluster to the small cluster there are more folks
wainting in line behind them for accounts on the large cluster.
This multi-level (of size?) architecture seems to be working
pretty well for providing services to our command.
Randy
Subject: Keystroke Monitoring
∂31-Jul-81 0721 Eric K. Olson <OLSON at DEC-MARLBORO> Keystroke Monitoring
Date: 30 Jul 1981 0128-EDT
From: Eric K. Olson <OLSON at DEC-MARLBORO>
To: TAW at SU-AI
cc: WorkS at MIT-AI
Message-ID: <MS"5(1631)"11748043074.24.545.10627 at DEC-MARLBORO>
As I said in a message to Human-Nets (once again, the two lists are
discussing similar things), I think a reasonably valid statistic
for keystroke monitors indicating performance of the secretary is
keystrokes per character in output document. This way the typist
that makes no errors will have fewer keystrokes (lower, better
score) than the typist that makes lots of errors to produce the
same document. This also takes care of the problem of a secretary
idling by typing jkl;jkl;jkl;jkl;jkl;. I personally do not condone
the use of keystroke monitors to monitor performance (I think that
management should not even be told the statistic is available).
This all assumes of course that the monitor is on a word processing
system used primarily for word processing. Programmers shouldn't
be subjected to keystroke monitors (I am a little more vehement
about this; it hits home), and fortunately the statistic is harder
to generate for programmers.
-Eric
-----
Subject: WorkS Digest V1 #1
∂03-Aug-81 0629 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #1
Date: 3 AUG 1981 0849-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Mon, 3 Aug 1981 Volume 1 : Issue 1
Today's Topics:
Administrivia - Welcome, Workstations - Harvard Apollo Experience,
Polls - OA System Developers & WorkS Census
----------------------------------------------------------------------
Date: 1 Aug 1981 (Saturday) 0956-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Administrivia - Welcome to the WorkS Digest
To All WorkS readers:
As you have probably guessed, we are making the workstation
discussion list into a digest. It shall be a daily digest.
One of the few things we are looking for is a moderator. If
you have the (a) interest, (b) the time, (c) easy and proper
access to the Network (MIT computers), and (d) the patience,
please drop a message in WORKS-REQUEST@MIT-AI.
Henry Dreifus
------------------------------
Date: 2 Aug 1981 (Sunday) 1422-EST
From: BUSH at HARV-10
Subject: Four Months with Two Apollos
We have had two Apollos at Harvard for about four months
now, and I have a few personal observations to contribute from
my experience with them.
The best way to describe them is as a state-of-the-art
product, with the emphasis on product. The Apollo seems to be
the best large-micro-based system available with a bit-mapped
display, Winchester disk, and high-speed local network. Since
it started a little over a year ago Apollo Computer has managed
to produce a very solid piece of hardware, and quite a bit of
software. We have had no trouble with the hardware, and the
software, while poorly documented and a tad flakey (we are a
beta test site), has been basically usable. The network file
system works, and, on our small network, file access is not
appreciably slower for remote files.
The Apollo is not, however, a state-of-the-art tool for
computer science research, nor does it claim to be. It is not
a Dorado nor a Star-with-Mesa. A lot of the folks at Apollo
came from Pr1me, and in order to produce a working, competitive
product, they built what they knew how to build for a market
they were familiar with (the engineering/scientific market).
The system was tuned for user programming in FORTRAN, not system
programming, with such things as interprocess communication and
software interrupts not supported. Now that its primary market
is academic, Apollo will put a number of these features in, but
system programming, and the kind of features it requires, are not
a fundamental target of the system software. The system also has
a rather unsophisticated human user interface. Some of this is
clearly a matter of time, but some things that I imagine people
at Xerox would consider basic, such as a mouse and non-confusing
windows, are not along yet. (The Apollo windows are confusing
because they are all full-screen width and bordered with a single
line, so it is difficult to determine which windows are on top.)
It seems that Apollo did not do a lot of research in designing
their product, but instead will be educated by their users.
Bill Bush
------------------------------
Date: 2 August 1981 11:34-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
Subject: Results of Poll
Here are the results of the "Are you actively working on an
Office Automation system" poll. The results surprised me very
much. Here are some of the numbers:
Responses 32
Working on a system 23
Not working 9
The "Not Working" column also contains responses from people
indicating that they were simply implementing OA functionality
on their home systems (e.g. not for commercial sale/distribution).
That was a value judgement on my part and may not be valid.
There were many very interesting responses but in order to keep
this message short I will exclude most. Two immediately caught
my eye and are reproduced here:
------------------------------
Date: 18 Jul 1981 13:22 PDT
From: XXXXX at PARC-MAXC
...
The Xerox redistribution list for WorkS currently contains
57 members. I don't know exactly how many of them (us) are
actually working on workstation design or implementation,
but I suspect about 75-80% are, in one capacity or another.
-- XXX
------------------------------
Date: 16 Jul 1981 21:05 PDT
From: Kimball at PARC-MAXC
Nearly everyone from Xerox on list, as you surmised...
Ralph Kimball
Manager CUSP Development, Xerox
------------------------------
In the first note I was asked not to reveal the sender. Based
on the numbers in the first message, we could probably skew
the results, but that is up to you.
As mentioned earlier, the raw responses are in the file
USERS3;LLOYD WORKS on the MIT-AI machine.
Brian
P.S. I too am actively working on a system. I am managing the
software development for the M/A-Com Executive Management
System (MEMS) which uses the Convergent Technologies
hardware.
B
------------------------------
Date: 3 August 1981 08:00-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
Subject: WorkS Census II
On 25 June, Randy Rivanciw proposed a census to give everyone
who wished, a chance to briefly describe who they are and what
their professional interest in personal workstations is. We
already have a variety of responses. However, a large number
of people have been added to the list since 25 June. Now that
the list population has stabilized, we want to give everyone a
chance to participate before making the results available.
If you would like to participate in this census and have not
already responded, please forward a brief description of your
interests in personal workstations to WORKS-CENSUS@MIT-AI.
Please do so promptly however, as we will make the results
available early next week.
Enjoy,
Roger
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #3
∂09-Aug-81 1202 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #3
Date: 9 AUG 1981 1418-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Sun, 9 Aug 1981 Volume 1 : Issue 3
Today's Topics:
Query - Smalltalk
----------------------------------------------------------------------
Date: 6 Aug 1981 1002-EDT
From: Bob Hyman <HYMAN at DEC-MARLBORO>
Subject: Smalltalk systems
What-all systems support smalltalk? Are there dialects of
smalltalk, as there are of FORTH? Do smalltalk systems come
without the graphics-oriented user interface?
Bob
------------------------------
Date: 9 August 1981 12:00-EDT
From: "The Moderator" <Duffey at MIT-AI>
Subject: Archived information about Smalltalk
Smalltalk has come up briefly in several earlier WorkS discussions.
For your convenience, a summary transcript of the archived material
on Smalltalk is included below. Complete copies of these messages
are available upon request from the archives.
-- RDD
... LRG, a group within PARC, has licensed Smalltalk-80 (the
only Xerox-authorized version of Smalltalk to be released)
to a number of micro- and mini-computer manufacturers. The
release consists of detailed specifications for the machine-
dependent kernel, plus a mag tape containing the rest of the
system (windows, editor, compiler, file system, etc., etc.)
Several of these manufacturers have made excellent progress
on implementing the system, to the point of having windows
appear on their displays. I can't comment on the specific
list of manufacturers, since we prefer to let them make
their own announcements. ... and we are currently working
out ways to license the system to manufacturers (and univer-
sities) beyond the original group. I can't comment on the
availability of Smalltalk for the Star, except to say that
the Star hardware is definitely powerful enough to support
Smalltalk.
-- <Deutsch at PARC-MAXC>
Smalltalk IS being released by PARC this summer. There
was a big presentation on the subject at this year's NCC.
Apple, DEC, HP and other companies are doing research
into implementing it on their machines. (In fact, one of
the primary Smalltalk implementors, Larry Tesler, is now
at Apple and was one of the speakers at NCC.) A huge
article on the subject will appear in the August issue
of BYTE.
The deal is that PARC gives you an "image" file on a
tape, which contains all of Smalltalk ready to run. To
run it, you have to implement an interpreter on your
machine for the 256 Smalltalk bytecodes. Just like you
can run Pascal, if you have a P-code interpreter.
-- Ron Newman <NEWMAN.ES@PARC-MAXC>
... Xerox intends to release a book on Smalltalk called
Smalltalk 80. This version of Smalltalk is intended to be
easily portable. There was some discussion within Xerox
legal about whether the Smalltalk virtual image would be
released. But the book which describes the interpreter
plus the virtual image would result in a very easily
portable language.
One could then port it to the machine of your choice,
including the STAR, assuming that you could PROGRAM
the STAR. When MESA gets released you will be able to
implement it in that: but a better place is microcode.
I haven't heard anything definitive about whether Xerox
intends to microcode the Dandelion (STAR workstation)
for Smalltalk.
-- Michael <mike at RAND-UNIX>
... Also, XEROX is now putting up Smalltalk on the Star,
for internal use. I have no idea, and I suppose neither
does XEROX, if they'll ever release it.
-- Chris Ryland <RYLAND at SRI-KL>
Ed Feigenbaum received the following message from Mr. R.E.
Bomeisler, Marketing Manager for Xerox EOS, in response
to repeated requests for more information about Dolphins
necessary for planning acquisitions. ...
*********************************************
"In our telephone discussion, Ed, you indicated that
Xerox was not providing you and potential users with
enough information to assist you in designing your
networks and planning for future growth. I would like
to apprise you of the steps we have taken at XEOS to
fill the information gap.
...
With regard to 1100/Interlisp performance, continual
improvements are being made in the code. The system
is five times faster than it was a year ago and signi-
ficant further improvement is expected.
...
In addition to Interlisp, XEOS is planning to
implement Smalltalk on the 1100. The schedule is
yet to be determined.
As a key ingredient of the overall 1100 program,
it is planned to release a version of Interlisp on
the Star processor after January 1, 1983. This will
provide Interlisp to future users on a very cost-
effective basis.
...
********************************************
-- Tom R. <RINDFLEISCH@SUMEX-AIM>,
forwarded to WorkS by <Geoff at SRI-CSL>
In response to a query from the other week, yes, the
Apollo Users Workshop did take place at Brown on 21-22
June. Users and potential users ... briefly described
what they are planning to do with their apollo's, Dave
Nelson and Bill Poduska talked in detail about the
company's plans for s/w releases and general growth,
Kim McCall from PARC-LRG talked about implementing
Smalltalk on an Apollo, and workshops were held about
porting unix, graphics, lisp, and tex. ...
Details of Apollo's plans discussed at the mtg are
confidential. Contact me for a list of participants
(w/phone, arpa addresses) that can be contacted for
more direct info, or for a short (3 sentence) summary
of what the participants said they'd be doing with
the Apollos.
-- Marc Brown in care of <Andy.VanDam at CMU-10A>
The August issue of BYTE is devoted to Smalltalk. The
good folks at Xerox PARC contributed quite a bit to the
issue. I'll refrain from further comment till I've read
the thing.
-- <decvax!duke!unc!smb at Berkeley>
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #4
∂12-Aug-81 0247 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #4
Date: 12 AUG 1981 0522-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Wed, 12 Aug 1981 Volume 1 : Issue 4
Today's Topics:
Query - Micro benchmarks, Reply - Smalltalk
----------------------------------------------------------------------
Date: 11 Aug 1981 1917-PDT
From: Stevan Milunovic <Milunovic at SRI-KL>
Subject: Micro Benchmarks
Has anyone performed, or seen documentation concerning,
benchmark comparisons of micros commonly used in
workstations/personal computers? Specifically, the Z80,
8086, M68000, LSI-11/2, LSI-11/23. Please send replies
directly to me and I will compile the results and submit
to works. Thanks. -Steve
------------------------------
Date: 11 Aug 1981 08:41 PDT
From: Adele at PARC-MAXC
Subject: Xerox Smalltalk
Various messages have been sent on this distribution list
relative to the release of the Xerox Smalltalk-80 (tm) system.
The messages in general are inaccurate or not complete because
plans for general distribution are not yet set. At this time,
for individuals to obtain information relative to their own
needs, you can contact me directly via telephone or
non-electronic mail.
Adele Goldberg
Xerox PARC
Learning Research Group
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #5
∂13-Aug-81 0624 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #5
Date: 13 AUG 1981 0740-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Thu, 13 Aug 1981 Volume 1 : Issue 5
Today's Topics:
Reply - Micro Benchmarks, FYI - IBM's Personal Computer
----------------------------------------------------------------------
Date: 12 Aug 1981 2246-PDT
From: Stevan Milunovic <Milunovic at SRI-KL>
Subject: Micro Benchmarks Results
Many thanks to those who responded to the micro benchmark query.
I have summarized the benchmarks reported in the April 1/81 issue
of EDN, but the article should be read for details concerning the
benchmarks. It appears that the 68000 is the hands down winner,
unless you need floating point processing and can't wait for the
chip (floating point benchmarks were not performed in the report).
I have appended messages (edited to remove redundancy) from those
who responded to the query.
Benchmark tests were compiled at CMU in 1976, and coded by each
manufacturer.
MICRO | LSI-11/23 | 8086 | 68000 | Z8000 |
-------------+------------+-------------+-------------+-------------+
BENCHMARK | Code| Time | Code| Time | Code| Time | Code| Time |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
I/O Interrupt| 20 | 114 | 55 | 126 | 24 | 33 | 18 | 42 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
I/O w/FIFO | 86 | 1196 | 85 | 348 | 118 | 390 | 106 | 436 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Char. Search | 76 | 996 | 70 | 193 | 44 | 244 | 66 | 237 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Bit Ops | 70 | 799 | 46 | 122 | 36 | 70 | 44 | 123 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Linked List | 138 | 592 | 94 | - | 106 | 153 | 96 | 237 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Quicksort | - | - | 347 |1.2E↑5 | 266 |3.3E↑4 | 386 |1.2E↑5 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Bit Matrix | 152 | 1517 | 88 | 820 | 74 | 368 | 110 | 646 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Clock time: LSI-11/23 = 3.3 MHz
8086 = 10.0 MHz
68000 = 10.0 MHz
Z8000 = 6.0 MHz
----------------------------------------------------------------------
From: Frank J. Wancho <FJW at MIT-MC>
Subject: Micro Benchmarks
ComputerWorld has been running a series of benchmark articles
over the last six months or more and periodically publish
accumulated summaries of the results in each category.
--Frank
----------------------------------------------------------------------
From: Nowicki at PARC-MAXC
Subject: Re: WorkS Digest V1 #4
Forest Baskett has the famous "Baskett Benchmark" that has been
run on machines like Dorados, Dolphins, Altos, 10s, 20s, Vaxen,
and MC68000 in both C, "hacked" C and Pascal. The results
are very informative. I would like to see the results on other
microcomputers. By the way, we get almost 40% VAX/780 performance
on the 8 MHz 68000 in this test, which is a small, integer only,
compute bound puzzle solver.
-- Bill
----------------------------------------------------------------------
From: CAIN at SRI-AI
Subject: Micro benchmarks
The April 1, 1981 issue of EDN has a number of benchmarks
between the LSI-11/23, the 68000, the Z8000, and the 8086.
They are taken from a more complete study done at CMU which
I was hoping to find one of these days.
Since these benchmarks omitted floating point tests, I
performed a couple informal ones on a 68000 with Doug Beck
here at SRI. To do 10000 iterations of a floating point add,
subtract, multiply, and divide took 71 seconds (implying 1.75
milliseconds per operation) using Whitesmith's C compiler and
104 seconds using Motorola's PASCAL compiler.
When talking to Motorola about this sluggish performance,
they mentioned that the 68000 has a fast floating point PROM
in development which has done floating-point multiplications
(in software!) in 35 micro seconds. This compares very well
with the LSI-11/23's floating point hardware times.
Also C makes all floating point numbers to double precision
before doing the implied operation, meaning much of that 71
seconds was devoted in going "float-to-double" and
"double-to-float". According to my calculations, the 68000
is capable of that 35 microsecond time easily (roughly 100
to 150 clock states would be required), and since it has the
most support (cross compilers on the VAX, etc), I think it is
the preferable chip. It is promised that the floating-point
support will be built onto the chip mask so that some new
instructions will manipulate floating point numbers directly.
I am seriously weighing the choice of VAX vs 68000 for a new
project (where cost may outweigh the greater power of the VAX).
... Ron
----------------------------------------------------------------------
------------------------------
Date: 12 Aug 1981 2130-PDT
From: Charles B. Weinstock <Weinstock at SRI-KL>
Subject: New IBM Personal Computer
Business Day : IBM Personal Computer
By ANDREW POLLACK
c. 1981 N.Y. Times News Service
NEW YORK - The International Business Machines Corp., the
giant of the computer industry, is thinking smaller: Wednesday
it introduced a personal desk-top computer for use at home,
in schools and in business.
Although the announcement had been expected for months,
it still sent reverberations through the industry.
Besides representing a dramatic change in image for IBM and
marking its entry into consumer electronics, the endorsement
of personal machines by a company whose name is practically
synonymous with computers is expected to stimulate the growth
of the business.
And IBM could pose the stiffest challenge yet to Apple
Computer Inc. and the Tandy Corp.'s Radio Shack division,
the current leading vendors.
"It's one of the most important announcements we've seen
in the industry," said Christopher Morgan, editor in chief of
Byte, a personal computer magazine.
"People will now know that personal computers are not a fad
or a flash in the pan," said Michael McConnell, executive vice
president of Computerland, a chain of a retail stores that will
market the new IBM products.
The price of the machines will range from $1,565, for a
simple system that will require users to provide their own
television screens and cassette tapes, to more than $6,000 for
the most elaborate versions. In addition to Computerland, the
line will be sold through several new business-machine stores
being started by Sears, Roebuck & Co., by IBM's own three retail
stores and directly by IBM to large corporations.
By most accounts of analysts and others connected with
the personal computer business, IBM's machine is impressive
technologically, not because of any single breakthrough, but
because of a combination of good features and sound engineering.
The new model uses a microprocessor capable of handling
16 bits of information at a time, which will permit the machine
to handle data more quickly and perform more complex tasks than
most other personal computers, which have 8-bit microprocessors.
The machine, depending on the model, can store 16,000 to more
that 260,000 characters in its memory.
But analysts disagreed on whether the price would be low
enough to knock Apple or Tandy out of the ring.
In Fort Worth, Garland P. Asher, chief of financial planning
for Tandy, said he was relieved in two ways. "I'm relieved that
whatever they were going to do, they finally did it," he said.
"I'm certainly relieved at the pricing. They haven't introduced
anything that's going to rewrite the ground rules."
Comparing prices is difficult, however, because the machines
come in different configurations and are not directly comparable.
McConnell, of Computerland, which sells both Apple machines and
the IBM home computer, said that in some typical configurations
the IBM machine was several hundred dollars more expensive than
the Apple II, Apple's popular brand. Yet the IBM device is
slightly less expensive than a typical configuration of the
newer, more powerful Apple III.
Other factors such as the availability of programs for the
computer and marketing are equally important, analysts said. IBM
will have fewer retail outlets and fewer programs initially than
Apple and Radio Shack. Yet, Aaron Goldberg, an analyst with the
International Data Corp., a Framingham, Mass., consulting firm,
said IBM's direct sales staff could be a potent force in selling
to leading industrial companies, who might buy dozens of desk-top
computers at a time.
Chances are, there will be room for all the companies, many
analysts believe. The personal computer market is growing
explosively, although accurate figures are hard to get because
there is no clear distinction between home computers, personal
computers for other users and desk-top computers designed for
business use.
International Data estimates that 327,000 desk-top computers,
ranging in price from several hundred dollars to $20,000, were
sold in the United States in 1980, and projects that this total
will increase to 1.3 million by 1985. In dollar volume, the
market is expected to grow from $2.4 billion last year to $9
billion in1985.
According to estimates by International Data and others,
there are approximately a million personal computers in use,
with the largest application being for business and professional
uses. The home and education markets are still small, but are
expected to explode.
When the new computer becomes available in October, the
program offerings will include Visicalc, a popular business
forecasting program; three business and accounting packages
by Peachtree Software; Easywriter, a word-processing package,
and Microsoft Adventure, a fantasy game. The software,
however, will sell in some cases for about twice the price
of the equivalent programs sold for use on other machines.
IBM is also allowing anyone else who wants to do so to
write programs for the IBM machine, which the company would
evaluate. If the programs were accepted for marketing, the
writer would be paid a royalty on sales of the program.
A veritable cottage industry of computer buffs has sprung
up to write programs for other personal computers, and the
abundance of such home-grown programs is largely responsible
for the market strength of the Apple and Tandy computers.
IBM also said it would make its computers nearly compatible
with some other home computers, so programs written for those
machines could be transferred to the IBM model.
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #6
∂14-Aug-81 1101 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #6
Date: 14 AUG 1981 1025-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Fri, 14 Aug 1981 Volume 4 : Issue 6
Today's Topics:
Workstations - IBM's Personal Computer, Micro Benchmarks
----------------------------------------------------------------------
Date: 13 Aug 1981 1159-EDT
From: Willie Lim <WLIM at MIT-XX>
Subject: IBM Personal Computer
IBM announced its new 8080 based personal computer yesterday.
The prices range from $1500 to $6000 (approx.). It seems
that the system has color graphics. Does anyone has any
more details on the system? What is the OS on the system
and what are options?
Willie
------------------------------
Date: 13 Aug 1981 0813-PDT
From: Stevan Milunovic <Milunovic at SRI-KL>
Subject: Micro Benchmark Units
The units in the benchmark chart sent Aug 12 were bytes for
code, and microseconds for execution time. Sorry for the
omission. -Steve
------------------------------
Date: 14 Aug 1981 0448-PDT
From: SCHIFFMAN at SRI-KL
Subject: Benchmarking new Micros
I forget where I first heard it said that benchmarking was Advanced
Lying With Statistics....
I looked rather carefully at the EDN benchmarks when they first
came out. I took these more seriously than usual because:
They were in Assembly language; therefore they measure
programmer skill plus machine performance, as opposed to
higher-level-language benchmarks which measure programmer
skill plus machine performance plus compiler quality.
(Worse yet are benchmarks written in different languages
for different machines which throw "language- quality"
into the mix... or benchmarks running on time-sharing
systems that end up measuring scheduler fairness and
disk performance.)
They were written by employees of the respective manu-
facturers who were likely to be skilled with the given
architecture. This also removes the possibility of
unfair advantage given due to hidden prejudices.
A reasonable coverage of routine types were made that
collectively might represent "general performance".
(Including interrupt service routines was a good move,
for example.)
Nevertheless, the benchmarks were about as useless as benchmarks
usually are!
To pick some specific nits--
Although there was ONE environmental parameter supplied (the
clock speed for the given processor) there was no mention of
what memory performance is required to run at that speed
without wait states. I believe it is the case that a 10Mhz
8086 can run with memory much slower (and therefore cheaper)
than a 10MHz 68000. Nor is it mentioned what the availability
of the part is at that clock rate. Did you know that a 10MHz
8086 is $200 cheaper than a 10Mhz 68000? Maybe if you paid
that kind of money to Intel they would sell you a 16MHz part!
The benchmark specifications had loopholes in them which
were taken (quite understandably) to differing advantage.
For example (as best as I can remember) the interrupt
service benchmark did not specify that context had to be
completely saved. The Intel programmers went ahead and
saved all registers anyway (a reasonable thing for a
service routine to do). The programmers for the other
machines only saved the minimal context necessary to meet
the specification.
So much for GOOD benchmarks!
Any yet one often hears that "CPU X is 20% faster than CPU Y"
based on even less careful comparisons.
{BTW, I'm planning to use the 68000 in my next system. And
I do think that is much faster than the 8086 for the things
I want to do. But it's very likely a bit slower (for what
I want) than the Z8000. Don't forget that there are other
reasons for choosing a CPU than how fast it goes.}
Most CPU designers, when pressed, will agree that there is no
reasonable way to collect a small set of general metrics that
will characterize machine performance. To find the fastest
among several computers "in the same performance class" can
only be done by carefully attempting to model the application
for which the machine is to be used. If you are lucky, this
can be as simple as designing your program and coding the
inner loops for each machine to be considered. If you're not
so lucky, you might spend a year building a workload simulator
and still not know how different things will be if you get a
different disk controller.
Doing it right, of course, can be very hard. It's much easier
to refer to a list of how long a quicksort of 100 items takes
for every machine ever invented.
Joseph Weisenbaum (in "Computer Power and Human Reason") tells of
the story about the drunk repeatedly walking around a lamp post
at night. A passing policeman asks him for an explanation. The
drunk replies that he lost his keys--
Cop: "Oh, so you lost them under the lamp post?"
Drunk: "Naw, lost 'em over there." (Waving at the distant
darkness).
Cop: "So why look for them under the lamp?"
Drunk: "Silly! 'Cause the light's so much better here!"
-Allan
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #7
15-Aug-81 1143 DUFFEY at MIT-ML (Roger D. Duffey, II) WorkS Digest V1 #7
Date: 15 AUG 1981 1355-EDT
From: DUFFEY at MIT-ML (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Sat, 15 Aug 1981 Volume 1 : Issue 7
Today's Topics:
Micro Benchmarks
----------------------------------------------------------------------
Date: 14 Aug 1981 15:28 EDT
From: Marshall.WBST at PARC-MAXC
Subject: Micro Benchmarks
A salesman from Intel was here this week and said that EDN has
retracted its benchmarks and will run another set. He said that
the new numbers show the 8086 only 10-15% slower than the 68000.
He said the retraction would be in the next issue.
Sidney Marshall - Rochester N.Y.
------------------------------
Date: 14 Aug 1981 11:36 PDT
From: Kosower at PARC-MAXC
Subject: Re: Benchmarking new Micros
Worse yet, benchmarks can be doubly deceiving, since they
may induce you to choose a micro for all the wrong reasons.
Unless you have a very specific application in mind, or
unless you plan to design and build your own operating system
from scratch, software development facilities, system quality,
and especially user interface quality are extremely important.
A Dorado, for example, may run faster than greased lightning,
but it would be about as useful as an F-15 powered by turboprop
engines if it had IBM-quality software running on it. After
all, most of us do not want to write reams and reams of code
in some J-random processor's assembly language (more so if it's
microcodable); so quality of the high-level language available
and quality of the compiler ARE important. Furthermore, most
applications change, and even with changes, their lifetime is
limited, so that other development facilities (editor, debugger,
etc.) are ALSO important. If it takes you 10 times longer to
write a program that will take 10 times longer to debug and will
eventually run 10 times slower, on processor A whose raw speed
is 10 times greater than that of processor B, which one would
you choose? Choosing B will save you time, to say nothing of
frustration, even though it is a "slower" processor. These are
not idle thoughts: an IBM 370/168 has tremendous raw speed, but
some of the cruftiest software ever written makes it seem slower
than the US Postal Service. Admittedly, almost all of the
software for micros such as the 8086 and 68000 is pretty awful,
but I still think it's worth keeping the above considerations
in mind. As Allan points out, just because something is easy
to measure does not mean it's useful or even meaningful.
David A. Kosower
------------------------------
Date: 14 August 1981 1832-EDT (Friday)
From: David.Lamb at CMU-10A
Subject: EDN benchmarks
Allan Schiffman may be right that the EDN benchmarks are
"about as useless as benchmarks usually are," but the MCF
(Military Computer Family) test specifications on which
they were supposed to be based *can* be used in a sensible
fashion to evaluate a computer architecture. The original
experiment design was set up at CMU with the co-operation
of one of the members of out Statistics department, who
designed the experiment to separate variance on the tests
into differences based on programmers, particular tests,
and the architecture itself. The notion was to see how
good the *architecture* (instruction set, visible registers,
etc.) was, rather than any particular implementation of the
architecture. Several different measurement scales were
set up. One measured the number of bytes need to encode
the programs, another measured the memory accesses needed
in an idealized implementation, and the third measured the
amount of data transferred between registers in the idealized
implementation. I'm a little disappointed that the tests are
being used now for a different purpose; it's not clear to me
that you want the same kinds of tests to do a comparison of
particular implementations of the architecture, as was the
case in the EDN tests.
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #8
∂18-Aug-81 0804 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #8
Date: 18 AUG 1981 0811-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Tue, 18 Aug 1981 Volume 1 : Issue 8
Today's Topics:
Workstations - IBM's Personal Computer, Micro Benchmarks
----------------------------------------------------------------------
Date: 17 Aug 1981 1331-PDT
From: Rubin at SRI-KL
Subject: IBM Personal Computer
For those of you who stay in touch by computer rather than paper
or radio: Here's the latest on the IBM PC. It's a three-piece
unit, VERY slim nice-looking keyboard, with basically the same
key layout as the 5250 series. The display looks cosmetically
the same as a displaywriter's, and sits on a logic box with dual
diskettes. Inside we have an 8088, up to 256K, five expansion
slots, 80x25 screen memory with graphics 320x200 or 640x200.
Figure it out, that means an OK but not great 8x8 character
cell. The unit displays up to 16 foreground colors on 8 back-
ground colors (but I doubt if all those are available in the
graphics modes). And you get a sound generator and built-in
speaker to boot!
The thing is totally modular; even the I/O cards are separate!
For $ 1,565 you get a keyboard and logic unit with 16K RAM and
a Basic interpreter in 40K ROM. A cassette interface is built
in, I think; but no diskette or monitor at this price -- you
use your TV set. Of course you can add one or two minidiskettes,
lots more memory (16-64k increments), a B&W monitor (no color
monitor was mentioned), RS-232C interface card, matrix printer,
a joystick/paddle interface (but you have to buy somebody else's
joysticks and paddles); and maybe the kitchen sink. A "business
configuration" with 64K, dual diskettes, printer, and "color
graphics" goes for about $ 4,500.
The big news might be the software -- there's plenty of
it. If you don't like their idea of a diskette OS or Pascal
compiler or word processor, you can try USCD Pascal or CPM-86,
coming soon from Softech and Digital Research. (Gee, and I
was looking forward to JCL). And then there's Visicalc, three
Peachtree business applications, Microsoft Adventure, 3270
emulation on the way, and a new IBM Software Publishing outfit
(!**8). It looks like they read Byte.
Where can you get it or ogle at it? Try your local Sears,
Computerland, or IBM store (or DPD sales rep, if you're a
big banana).
Darryl Rubin
SRI International
------------------------------
Date: 17 Aug 1981 1220-PDT
From: Rubin at SRI-KL
Subject: Micro benchmarks
This may sound like an answer that begs the question. But THE
one true way to benchmark a micro depends entirely on your point
of view. (As you see, I have an unmatched knack for discovering
the obvious.) CPU architecture and instruction throughput matter
the most to designers of CPU boards for number-crunching and other
compute-bound stuff. Good I/O architecture and throughput score
highest to OEMers of communications and data base boxes. Good
compilers, spiffy user interfaces, and software tools (Xerox we
hear you!) matter the most to the rest of us system developers
and end users. What you will "see" is what you should measure.
Just to be exhaustive if not obsessive, I'll mention the sometimes
overlooked importance of good I/O controllers and peripherals,
especially big fast disk; a W-I-D-E choice of hardware and
software offerings; reliability, support, and the prospects for
compatible future enhancement. Most of all, vendor credibility
and track record. How do I benchmark thee, have I counted all
the ways?. . .
Darryl Rubin
SRI International
------------------------------
Date: 15 AUG 1981 1411-PDT
From: STEWART at PARC-MAXC
Subject: Benchmarks
Quote from ???: "There are lies; there are damn lies;
and there are benchmarks."
-Larry
------------------------------
End of WorkS Digest
*******************
Subject: Announcements - ANSI Standards Comm. & NCC82 Call for Papers
∂31-Jul-81 0755 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Announcements - ANSI Standards Comm. & NCC82 Call for Papers
Date: 31 July 1981 06:00-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
WorkS Announcements
----------------------------------------------------------------------
Date: 29 July 1981 01:31-EDT
From: Steven T. Kirsch <SK at MIT-MC>
Subject: X3V1 comm. for ANSI Standards in the area of Office Systems
There are four working groups:
1. User interface requirements
2. Terms and functions for office systems
3. Distribution of information (e.g., message interchange format)
4. Text communications (e.g., page image format)
They welcome new members. West coast people are especially invited
to participate. Meetings are held in Washington, DC.
For further information, contact:
L. M. Collins, Chairman
X3V1 IBM Corp
2300 One Main Place
19th Floor
Dallas, TX 75250
------------------------------
Date: 28 July 1981 17:59 edt
From: Frankston at MIT-Multics (Bob Frankston)
Subject: NCC 1982 Personal Computer Sessions -- Call for papers etc.
The 1982 National Computer Conference will have a track (i.e.,
a group of sessions) on personal computers. This means that
the papers will be refereed and appear in the proceedings.
This is in contrast to past years in which there was a
separate, unrefereed "subconference".
This reflects the growth and importance of personal computers.
But it is also a challenge. We must organize a new set of
sessions and get new referees. Part of this challenge is in
finding a balance between sessions on the mature areas in
personal computing and capturing the innovation in ongoing
research and development, both in academic and commercial
projects. Workshops might provide a better forum for the
latter.
Some of the possible topics include:
- what are personal computers -- the definitions range
from Alan Kay's dynabook, to miniature mainframes to
workstations.
- what personal computers are not.
- specific applications and issues such as wordprocessing
(though word processing also falls under office automation)
- Protocols and standards
- Networking as it relates to personal computers. This
can represent both local area networks as well as ad
hoc telco networks.
- Operating systems -- both traditional and new concepts
- Languages
- Consumer computers -- issues in design, implications of
a software marketplace.
- Education -- traditional and otherwise, computer and
noncomputer
- Implications and relationships to other fields both
within the industry and in the rest of the world.
Societal interactionals.
- Hardware trends and issues
- Games, both recreational and educational.
I am on the NCC steering committee and am in charge of
organizing/creating these sessions. If you have any
suggestions or comments, and if your are interested in
participating by writing a paper, refereeing or whatever,
please contact me either as:
nccpc82.SoftArts at MIT-Multics
or
Bob Frankston
Software Arts, Inc
PO Box 527
Cambridge, MA 02139
or 617-491-2100.
------------------------------
End of Announcements
********************
We would like to report on the SUN workstation at ncc-pc.
Please send me an author's kit at:
Andreas Bechtolsheim
PO BOX 3005
Stanford, CA 94305
We might also help to review some papers.
Subject: WorkS Digest V1 #9
∂22-Aug-81 0646 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #9
Date: 22 AUG 1981 0917-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Sat, 22 Aug 1981 Volume 4 : Issue 9
Today's Topics:
Workstations - IBM's Personal Computer
----------------------------------------------------------------------
Date: 18 Aug 1981 1406-EDT
From: Willie Lim <WLIM at MIT-XX>
Subject: IBM Personal Computer
For more details on the IBM new personal computer see a full page
ad (page 16) in Monday's Wall Street Journal (8/17/81). There is
a number one can call : 1-800-431-2670. But Rubin's mail to
WorkS seems to have quite a good description of the system.
Willie
------------------------------
Date: 18 Aug 1981 1415-EDT
From: Willie Lim <WLIM at MIT-XX>
Subject: IBM new PC
There is a rumour that the S-100 bus is (or going to be) on the new
IBM PC. Is this true?
Willie
------------------------------
Date: 20 Aug 1981 (Thursday) 1737-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: IBM Personal Computer
Would someone collect information on the IBM Personal Computer,
and then send it out to the list? Here is all that I know about
it:
Processor Class: 8086 (lets face it, its a display-writer)
Up to 256 K memory
Either Floppy (avail now) or Winchester drives.
Can run DOS, a version of CP/M or IBM's own OS.
Will have EasyWriter & VisiCalc; not sure on Wordstar.
It is clearly going to be more powerful in the long run over
8080 class microprocessors.
For more info, they have an 800/431-2670 number for information
pacquets.
Hank
------------------------------
End of WorkS Digest
*******************
∨
Subject: WorkS Digest V1 #10
∂31-Aug-81 0013 DUFFEY at MIT-ML (Roger D. Duffey, II) WorkS Digest V1 #10
Date: 31 AUG 1981 0142-EDT
From: DUFFEY at MIT-ML (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Mon, 31 Aug 1981 Volume 1 : Issue 10
Today's Topics:
Workstations - IBM's Personal Computer, Working While Flying
----------------------------------------------------------------------
Date: 23 Aug 1981 1700-EDT
From: GILBERT at MIT-XX (Ed Gilbert)
Subject: IBM's personal computer: S100?
I saw a sales presentation and a couple of prototypes the other
day. From what I remember, the cards did not look like S100
cards. During the presentation, they promised to publish the
bus specs, so we can assume that it isn't S100. However, they
seem to be encouraging a plug-compatible market, so it should
soon grow to be as large as the S100 market.
Someone sent a message to this list some time ago describing
the system. I learned little of significance at the presentation
that was not in that message. I do want to clarify something
that could cause confusion. The DOS that is offered with the
personal computer is not the same one that runs on the main-
frames. If you think about it that would be very difficult
to do, but IBM hasn't been very clear about it. I am told
the new DOS is of the same flavor as CP/M.
------------------------------
Date: 26 August 1981 1153-EDT (Wednesday)
From: Marc.Donner at CMU-10A
Subject: IBM Personal Computer
I saw some of the discussion of the IBM personal computer
in the Apollo bboard at CMU. I just left IBM Yorktown
Heights and I brought with me a copy of the 'blue letter'
that announced the PC. I will be glad to send you any
information from it that you want ... it is public
information. I don't have it with me physically right
now, but here is some of the gist:
In the beginning IBM will be selling two basic configurations:
Configuration 1 includes 'System Unit', Keyboard, 48K RAM,
40K ROM, floppy disk controller and one floppy (5-1/4 inch
minifloppies). Configuration 2 is same as configuration 1
with addition of another 16K RAM (total 64K) and the other
floppy. The system unit has capacity for up to five cards.
One option that you MUST buy before you may use the system
is one of three video interfaces. One interface connects
to the IBM monochrome display, one connects to a TV modulator,
and one connects both to the monochrome display AND to the
printer. The list price for Configuration 1 is about 2300
dollars. For configuration 2 the list is about 3000 dollars.
Oh, one thing that is also included in the Configuration 1
and 2 systems is the Asynchronous Communications Interface.
All software beyond the ROM Basic (by MICROSOFT) is extra
cost. Asynchronous communications software is $40, Pascal
is $300 (requires two floppies and big memory, I think),
Adventure is $30 ... more details when I have the blue
letter in my hand. The minimal systems (system unit, 16K
RAM) will only be available from Sears and Computerland.
Volume discounts are available ... 5% for more than 20
units on up to 15 or 20% for >100 units.
The processor is an Intel 8088, which is the 8 bit bus version
of the 8086 ... it is a 16 bit machine shouting through a small
hole. The processor cycles at almost 5MHz. Assuming three
byte instruction and one data fetch or store per instruction,
there will be five memory transactions per instruction ... if
memory cycles at system clock speed (I think that this is so)
then they get about 1 microsecond per 8086 instruction. The
first 64K of RAM plug into sockets on the main processor board
... you don't have to buy the RAMs from IBM ... you can get
the chips from a distributor and save bucks.
Almost all of the software (read ALL) is from outside. The
floppies and the printer are also OEM components that IBM
buys. The monochrome display is capable of displaying 25
lines of 80 characters ... the TV interface is limited to
25 lines of 40. The monochrome display may have monochrome
graphics ... the announcement is quite vague.
I priced out the nicest combination of goodies that would
go together in the box ... two floppies, 192K RAM, printer,
display, communications, and it came to about $6K sans
software.
Please let me know if you want more details.
Marc
------------------------------
Date: 27 Aug 1981 1743-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Working while flying - airborne phones coming
From the 26 Aug 81 issue of MIS Week newspaper:
W.U. TO ACQUIRE 50% OF AIRFONE
Upper Saddle River, N.J.
- Western Union Corp. said last week it has agreed to acquire
a 50 percent interest in a new communications system, owned by
Airfone Inc., that will allow passengers on commercial airlines
to place a telephone call while in flight.
According to Western Union, Airfone has received a developmental
license from the Federal Communications Commission (FCC) to
provide a nationwide, fully automatic air-to-ground radio
telephone communications service.
Initially, Western Union said, service will be provided through
air-to-ground telephones installed in wide-bodied aircraft, which
in turn will be linked with multiple ground stations providing
coast-to-coast coverage. It said a passenger would be able to
place a call by using portable telephones located in various
sections of the aircraft.
The system, it said, is expected to be operational during the
second half of next year.
------------------------------
Wonder if I'll be able to use my TI745 with this service...or
better yet, the still-to-come portable CRT connected to my
still-to-come stand-alone home workstation? -Rich Zellich
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #11
∂01-Sep-81 0933 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #11
Date: 1 SEP 1981 1042-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Tue, 1 Sep 1981 Volume 1 : Issue 11
Today's Topics:
Workstations - IBM's Personal Computer, Working While Flying
----------------------------------------------------------------------
Date: 31 Aug 1981 08:20:52-PDT
From: SomeoneOnUUCP at Berkeley
In-real-life: Steven M. Bellovin
Location: University of North Carolina at Chapel Hill
Reply-to: "Steven M. Bellovin in care of" <CSVAX.upstill at Berkeley>
Subject: New IBM system
I have a few questions about the thing, and I'd appreciate any
information anyone has gathered.
a) is it S-100 compatible?
b) Is it program compatible with their 8086-based Datamaster?
c) Can one get 8-inch floppies for it?
------------------------------
Date: 31 Aug 1981 1214-PDT
From: Rubin at SRI-KL
Subject: IBM PC, last round
A last note on the IBM PC, and then maybe we can get back to
discussing REAL research workstations (which the IBM PC probably
isn't quite).
I got the literature pack IBM sends out, and would like to correct
something Marc said in his recent note. This literature mentions
only two video interfaces -- one for the IBM monochrome display and
one for a color graphics display. The monochrome board includes a
printer interface. If you get the color board, you buy a separate
printer interface. The color board has 16K RAM for color storage,
used like this:
Text mode -- 16 foreground colors, 8 background
Graphics mode -- 4 colors 320 x 200 (might there be a lookup
table ???), 2 colors (B&W) 640 x 200
The graphics board puts out RGB and composite video. IBM does
not (yet) sell a color graphics monitor or RF modulator, but if
you buy somebody else's, the graphics board will accommodate it.
If you're seriously interested in this PC, be wary of a couple
things: First, the five slots probably isn't enough if you want
> 128 K of memory and color graphics; with luck they'll add a
bus extender. Also, I'm wondering whether any of the announced
software really supports more than 64K in any useful way, or how
soon it will. (Given the slowness of diskettes, you'll need the
extra RAM for decent response time, if the software will only use
it properly). Third, I don't believe the IBM DOS applications
can send their output to the ASCII port; if true, you'd have to
buy their printer (and that's a loss because the printer doesn't
do graphics, or at least IBM doesn't claim it does).
Still, I think this PC has more pluses than minuses, compared
to Apples, TRS-80s, Xerox 820s, ad triviatum. Good hardware,
lots of software, lots of future enhancement, and lots of
support (maintenance contracts, even!). Look for IBM to add
a 5.25" Winchester and lots of color graphics software.
Now, about REAL workstations. I just read a rumor that about a
year from now DEC will be announcing a floppy-based, VLSI VAX
packaged as a workstation. Price about $ 15,000. Supposedly
it's already in beta test. Does anyone know more about this?
--Darryl
------------------------------
Date: 31 Aug 1981 0018-PDT
From: the tty of Geoffrey S. Goodfellow
Sender: GEOFF at SRI-CSL
Reply-To: Geoff at SRI-CSL
Unless you like getting 3 and 4 digit phone bills, I don't
think you'll want to use your terminal on AIRPHONE. Such
a service currently exists on some United DC-10's using
equipment sold by SKYTEL (or SKYPHONE) using the currently
allocated FCC Air-to-Ground Mobile channels. Last I heard
the charge for use was $15/first three mins (air-time), and
$3/ea. addtl min (air-time). This charge was IN ADDITION
to the Operator Assisted dialed call rate from the ground
base station you were going thru to the person you were
calling.
I have found the mobile phone I have in my car indispensable,
and have often wished for similar service on air plane
flights. I just hope that the license the FCC gave AIRPHONE
for its developmental system means it will operate on some
new frequency allocations, and hence, will be a 'new type
of service' and not subjected to the (excessive) rates on
the current system in use today.
P.S. Wouldn't this have been more appropriate for HUMAN-NETS?
[ It was addressed to HUMAN-NETS as well as to WorkS. It
was deemed appropriate for WorkS because of this list's
earlier speculations on using terminals while traveling.
I would like to take this opportunity to remind everyone
that almost all of the WorkS subscribers also subscribe to
HUMAN-NETS. The moderators will point out other discussion
lists to submitters when that seems appropriate. However,
the final decision of where to distribute something remains
with the submitter. -- RDD ]
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #13
∂03-Sep-81 0957 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #13
Date: 3 SEP 1981 1004-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Thu, 3 Sep 1981 Volume 1 : Issue 12
Today's Topics:
Query - Mesa availability, A book on Workstations,
Call for People - NCC '82 Personal Workstations track
----------------------------------------------------------------------
Date: 3 Sep 1981 (Thursday) 0753-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Mesa shall be released (?)
I have heard from two sources that Mesa - the programming
language for the Xerox Star, among other Xerox products,
will be released, and available for programmers to use.
Just how much and exactly when Mesa is coming out are two
interesting questions at this time.
Hank
------------------------------
Date: 3 Sep 1981 (Thursday) 0816-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Workstations -- a book ?
Personal Workstations Mailing list;
to all participants:
Computer Science Press of California is interested in making
WorkS a book. Sections on all the different personal computers,
and interesting areas such as local networks will probably be
addressed.
Please send me your comments in this matter. I would like to
use most of the information contained here already in WorkS,
as well as continue to put together more topics and 'chapters'
through continued input.
The way in which I foresee the book becoming a reality is by
having everyone who has expertise in an area write the appro-
priate chapter. I am still in the idea-cogitating stages of
this -- your input shall be most valuable.
If interested in helping, let me know!
Henry Dreifus
------------------------------
Date: 3 Sep 1981 (Thursday) 0821-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: WorkS in NCC'82 works.
This is a version of a message that Bob Frankston of SoftArts
sent to the Works users who are interested in getting NCC-82's
personal workstations track running and up and off the ground.
People are needed to help organize this thing, and do it right.
If you are at all interested in any aspect of what is below, or
have some ideas you think are important for the NCC please send
them along to Bob Frankston [Frankston.SoftArts@MIT-MULTICS].
Hank
--------------------------------------------------
1. What is personal computing.
This should cover some of the history of personal computing
(it is not a new idea) as well as the current explosion in
popularity and availability. A subtopic is "what is
programming". Traditionally it has been languages such as
Fortran and COBOL. What is it now?
2. Local Networks, Workstations
These are both popular topics these days.
3. Education/Social Implications
Issues beyond traditional CAI. Learning with and about
computers. What are the effects in the US society, in
other, possibly "less well developed" societies. What
are the myths such as "computers for kitchen recipies"
vs "computers are impossible for people to ever learn to
use". Society also affects computers. As the computation
becomes more accessible, more people will be programming
and affecting the machines.
4. Global Networks
This is actually a combination of the previous two --
what is the implementation of and the implications of
communicating computers. The emphasis is on the use of
such a capability be individuals as a means of access
and communication. Cable TV and information services
are both relevant to this as is electronic mail.
5. Software Environments/Operating Systems.
This covers both traditional operating systems work
as well as special machines for Lisp and Smalltalk.
Also relevant are tools, standards and protocols, and
languages. The emphasis is on the particular issues
for personal computing (this sometimes means small
computing, but not necessarily).
6. Hardware
The emphasis would be on developments that make the
computation more accessible for personal computing.
7. Applications.
There is not necessarily a strong distinction between
systems work and applications. Applications may include
individual ways of exploiting computers for personal use
or use of computers in environments such as homes and
offices. For example, workstations are both applications
and environments for applications.
8. Graphics
As it applies to personal computing.
9. Peripherals and I/O.
How is access to personal computing provided, how can such
systems interact with their users and their environment.
These are, of course tentative. Suggestions are stil welcome.
If you know of other people who would be interested in helping
or people you know of who you hink I should contact, please
send me a note (nccpc82.SoftArts at MIT-Multics).
Thanks.
Bob Frankston
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #13
∂04-Sep-81 1006 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #13
Date: 4 SEP 1981 0907-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Fri, 4 Sep 1981 Volume 1 : Issue 13
Today's Topics:
What is a Workstation?, Workstations - Xerox 1100
----------------------------------------------------------------------
Date: 3 Sep 1981 1703-PDT
From: Mike Leavitt <LEAVITT at USC-ISI>
Subject: Works Book
One of the issues that has weaved in and out of the discussion
here is why certain small machines are *not* workstations.
It would seem interesting for the definitive (for this year)
workstation book to discuss this issue, as well, and perhaps
to indicate just what would need to be done to the more common
small machines for them to qualify as workstations. I'm cc'ing
the list on this because I want to hear the flames about how
an Apple can NEVER become a REAL workstation, before I give
specifics!
Mike <Leavitt at usc-isi>
------------------------------
Date: 3 Sep 1981 0959-PDT
From: Richard R. Cower <COWER at SRI-KL>
Subject: Xerox
NO. 509
August 27, 1981
XEROX ANNOUNCES INTERLISP PROCESSOR
FOR ARTIFICIAL INTELLIGENCE RESEARCH
A compact computer system for use by research scientists in
artificial intelligence has been announced by Xerox Corporation.
The Xerox 1100 Scientific Information Processor includes a wide-
format, bit-map display, keyboard, and "mouse" pointing device.
It makes available the Interlisp-D software, an upward-compatible
extension of Interlisp, formerly available only on large, time-
shared computers.
The 1100 Interlisp system provides scientists with a computing
environment for conducting artificial intelligence research.
This research discipline has applications in engineering,
medicine, genetics, geophysics, robotics, and other fields.
Both the hardware and software were developed at the company's
Palo Alto Research Center in California. The system will be
marketed by Xerox Electro-Optical Systems in Pasadena, California.
Louis G. Karagianis, Vice-President of Marketing for Xerox
Electro-Optical Systems said, "The 1100 processor is intended for
use by research scientists in universities and large industrial
research laboratories, which are centers of activity for the
development of artificial intelligence techniques."
The system has 1.15 megabytes of memory and virtual address space
of 4 million 16-bit words. It also includes a 23-megabyte Shugart
disk drive and interfaces for the original Xerox 3-megabit-per-
second Ethernet, and for RS232 communications lines. All of this
equipment is housed in a 2.5-foot-high cabinet that fits under a
desk.
The display is a high-resolution unit with a 13" x 11" viewing
area (1024 x 808 pixels). The text portion of two pages can be
displayed side-by-side.
The Xerox 1100 includes a complete implementation of the Interlisp
virtual machine specification. In addition to the standard Inter-
lisp features, it offers new personal computer facilities, such
as a complete set of raster scan graphics operations and Xerox
Ethernet software.
Purchase price of the Xerox 1100 Scientific Information Processor
in the United States is $59,719; this includes a license for
use of the Interlisp-D software. Deliveries will begin in the
first-quarter of 1982.
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #14
∂08-Sep-81 0550 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #14
Date: 8 SEP 1981 0718-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Tue, 8 Sep 1981 Volume 1 : Issue 14
Today's Topics:
Query - Cheap touchpanel
----------------------------------------------------------------------
Date: 4 Sep 1981 1257-EDT
From: Kastner at RUTGERS (John)
Subject: Touch Panel
Do you know of any vendors that sell a touch panel terminal or
an add-on touch panel for an existing terminal? Either the actual
touch sensitive or the light array type would be acceptable. We
are looking for a panel that fits rights over the screen. We
would prefer one on which a finger would work but might consider
a light pen. We don't need high resolution and probably 16 X 16
would be sufficient.
The terminals that we've seen cost over $7000 and have fancy
graphics that we don't really need. What we would like is a
cheap way that doesn't require a lot of fancy code or hardware.
Thank you,
John Kastner
[ During July, WorkS discussed a variety of different workstation
input devices. A major portion of the discussion was devoted
to touchpanels. For your convenience, a transcript of this
discussion is now available in the file DUFFEY;WORKS TOUCHP
on MIT-AI. -- RDD ]
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #16
∂16-Sep-81 2316 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #16
Date: 16 SEP 1981 2315-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Wed, 16 Sep 1981 Volume 1 : Issue 16
Today's Topics:
Administrivia - Issue numbering, Input devices - Mice
----------------------------------------------------------------------
Date: 16 September 1981 22:55-EDT
From: The Moderator <Duffey at MIT-AI>
Subject: Administrivia - Issue numbering
Due to a combination of problems, the last three WorkS issues
were misnumbered. These issues, which were dated 3, 4, and
8 Sep., should have been numbered V1 #13, V1 #14, and V1 #15.
Today's issue is V1 #16 and it immediately follows the issue
dated 8 Sep. My thanks to everyone who pointed out these
errors.
-- RDD
------------------------------
Date: 16 September 1981 02:55-EDT
From: Steven T. Kirsch <SK at MIT-MC>
Subject: What is the "optimum" shape of a mouse?
Here's your chance to "shape" the future course of mouse-kind.
I would like to know what people think the ideal mouse should
be shaped like. Also, should there be less than three buttons?
Note that this is an optical design (the mouse slides on a
surface, rather than rolling) so comments about the mechanics
are not applicable.
Comments will be accumulated on MIT-MC in SK;MOUSE SURVEY
(no password needed to ftp).
Some comments I received so far follow. If you have any
opinions on these, please voice them. Some of the following
comments are mutually exclusive.
------------------------------
The Xerox mouse is too small. It doesn't fit the hand well/it
is hard to find.
The Xerox mouse is too large.
The ISI/TYMSHARE mouse is way too large.
Long buttons are great for accomodating various size hands.
The buttons should have good "bounce" to them to facilitate
double and triple clicking.
The MIT mouse (tan case) seems to be about the right size.
The mouse should have rectangular shape and edges. Any hand
contouring is doomed to failure because of the wide variety
of hand sizes.
The mouse should be rounded to fit the contours of the hand
(prolate hemi-spheroid). The hand should slip naturally into
a "home" position where the fingers rest on the buttons.
The mouse should not be "handed". This is to accomodate
lefties as well as two handed mouse applications.
The wrist must be able to rest on the table with the fingers
comfortably on the buttons. This is necessary for accurate
positioning.
There shouldn't be more than three buttons on the mouse
because two fingers are needed to move it around. Also,
coordination is difficult.
------------------------------
[ If you want a copy of the survey messages and cannot obtain
it yourself, please send a message to WorkS-REQUEST at MIT-AI.
We will be happy to insure that you receive a copy now. A
file containing all of the responses will be made available
for FTP distribution when the query is over.
-- RDD ]
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #17
∂21-Sep-81 0239 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #17
Date: 21 SEP 1981 0500-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Mon, 21 Sep 1981 Volume 1 : Issue 17
Today's Topics:
Query - Cell graphics algorithms,
Book - Audience and objectives, Workstations - MicroDaSys 68000,
Input Devices - TASA touchpanel & Apple mice
----------------------------------------------------------------------
Date: 20 Sep 1981 (Sunday) 0941-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Call for information, forwarded request
[Begin forwarded messages]
Date: 19 Sep 1981 2317-PDT
From: William "Chops" Westfield <BILLW at SRI-KL>
Subject: Need algorithms for Cell-organized graphics displays
Does anyone have references for graphics algorithms (line
drawing, polygon filling, etc) that have been optimized
for use with subcell style graphics display (such as some
terminals and many micros have)? I know Barrett & Jordan
have some articles in CACM (march,feb 1974) (I haven't read
them yet). Are there any others written since then?
Thanks
Bill W
[End forwarded messages]
------------------------------
Date: 20 Sep 1981 (Sunday) 1004-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Book.
The general opinion is to gear this book to the technical market-
place, the educational as well? I am not that high on having a
loose leaf type book, but that could be for the second volume,
an update service on all the new machines that are around.
I would be interested in what one would want to see in a book
such as this describing personal workstations, what sorts of
things should be stressed and so forth.
Hank
------------------------------
Date: 21 September 1981 02:50-EDT
From: Patrick G. Sobalvarro <PGS at MIT-AI>
Subject: Workstations - MicroDaSys 68000
There is a company in California called MicroDaSys, which claimed
in the latest issue of EDN to be selling a 68000 Unix system that
looks too good (and cheap) to be true. Two 12mhz 68000s (one for
virtual memory management, with demand paging), and a 6809 for
interrupt-driven I/O. Comes with 6 RS232 ports, running at up to
500k baud, and 4 parallel ports, with handshaking.
A multiuser system comes with 512k bytes of RAM in a 16M-byte
virtual space, 40M bytes of Winchester storage, and V7 Unix.
All for less than $20K.
Does anyone have any experience with these folks? Are they
delivering?
-pgs
------------------------------
Date: 19 Sep 1981 (Saturday) 2337-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Touch Panels: TASA
Product: Touch-Panel, x-y positioning
Price: $400.00 quantity 1, $150.00 in mass
Model: X-Y 3600
Principle: Capacitive Sensing, look at Xrx860 abortion
60x60 steps in square surface 5"x5".
Probably useful in augmenting user work-effectiveness.
Address: Touch Activated Switch Arrays, Inc.
2346 Walsh Avenue, Santa Clara
California, 95051
(408) 727-8272
Contact: Bob Abler, manager of marketing.
I'd be interested if there is a demonstrated use for touch panels
that are not a part of the screen, and if they have the ability
to be used for Office Automation? What also does one need from a
touch panel? More x-y points ?
Hank
------------------------------
Date: 19 Sep 1981 1806-PDT
From: Mike Leavitt <LEAVITT at USC-ISI>
Subject: Mice for Apples
Does anyone know of anyone who sells Mouses for Apples?
I presume they should plug into the game socket, and work like
a joystick plus the three button sensors. A couple of micro-
switches on the side would be nice to determine which of the
paddle controls would be activated.
Mike
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #18
∂24-Sep-81 2021 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #18
Date: 24 SEP 1981 0540-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Thu, 24 Sep 1981 Volume 1 : Issue 18
Today's Topics:
Input Devices - Touchpanels
----------------------------------------------------------------------
Date: 22 September 1981 19:40 edt
From: SSteinberg.SoftArts at MIT-Multics
Sender: COMSAT.SoftArts at MIT-Multics
Subject: TSD's
Xerox uses them to implement a mouse on a workstation. ArqMaq
put them on the arms of a chair and did gesture recognition so
they could control sound volume (circular motion), page viewing
(diagonal lines for forward and back), and so on. Gesture
recognition doesn't need hi-res.
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #19
∂16-Oct-81 0617 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #19
Date: 16 OCT 1981 0604-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
Reply-to: WorkS at MIT-AI
To: WorkS at MIT-AI
WorkS Digest Friday, 16 Sep 1981 Volume 1 : Issue 19
Today's Topics:
Technology - 32 bit Micros, Input Devices - Mice,
Workstations - Apple-O Arrival
----------------------------------------------------------------------
Date: 16 Oct 1981 0600-EDT
From: DUFFEY at MIT-AI
Subject: Welcome back (again) and goodbye (one last time)
This is WorkS V1 #19. It directly follows WorkS V1 #18 published
on 24 September. A long hiatus due to a lack of submissions, but
one that will not be repeated soon as WorkS turns its attention
to a variety of new and old topics over the next few weeks.
Welcome back.
As subscribers to some of the other lists already know, I will
soon begin a two year leave of absence from MIT to pursue research
with a private company. Starting with the next issue, Jon Solomon
<JSol at RUTGERS> will take over as WorkS moderator and maintainer.
Jon is already well known to subscribers to these lists as both a
moderator and subscriber. I hope you will welcome him with the
same cooperation and interest that you have always shown me. It
is the only thing that makes it possible to do this job. Thank
you and enjoy.
Roger Duffey
------------------------------
Date: 7 Oct 1981 (Wednesday) 0012-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: How far away are the 32 Bit micros ?
This is something that has not been introduced in too much
detail as of yet. With the forthcoming 432 32 bit-on-a-chip,
and putting it into a workstation/small multi-user machine
is of some interest. What does 32 bits really win over
16 bits?
Henry Dreifus
------------------------------
Date: 12 Oct 1981 2042-PDT
From: Jim Guyton <Guyton at RAND-AI>
Subject: Xerox Mouse
Xerox Mice fans:
Jack Hawley (owner of Hawley labs, maker of the Xerox
Alto mouse) has made a new license agreement with the
Xerox Corporation.
His new agreement will allow him to sell the mouse
to almost anyone, including for-profit companies.
Previously he was restricted to selling to Xerox
and non-profit educational institutions.
Developmental prototype (no case) available in January
for $750. Production quantities available mid-April
for about $425.
The number for Hawley Labs is (415)525-5533.
Mouse in quantity:
1-99 425
100 375
250 315
500 290
1000 280
------------------------------
Date: 11 Oct 1981 (Sunday) 2140-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Our APPLE-O arrived on Friday,
a review of it will be made in WorkS next week.
Hank
------------------------------
End of WorkS Digest
*******************
Subject: WORKS Digest V1 #20
∂21-Oct-81 2128 Jonathan Alan Solomon <JSol at RUTGERS> WORKS Digest V1 #20
Date: 21 Oct 1981 0713-EDT
From: Jonathan Alan Solomon <JSol at RUTGERS>
To: Works: ;
WorkS Digest Wednesday, 21 Sep 1981 Volume 1 : Issue 20
Today's Topics: Administrivia
Where are the 32 Bit WorkStations?
VideoDisks as Storage Devices
Mesa Manual Query
----------------------------------------------------------------------
Date: 21 October 1981 0642-EDT (Wednesday)
From: The New Moderator <JSol at Rutgers>
Subject: Hello! and Welcome to WorkS!
Hello,
Roger Duffey was a superlative moderator and it will not
be an easy job trying to match the quality of service which he was
famous for. I will, however, do my best and hope that I can at
least comes close to the fine work Roger has done. There is no
question that the ARPAnet community will miss his fine services as
moderator.
Once again, I wish to express my appreciation at being given the
responsibility of maintaining this digest, and I hope that the
transition between moderators will be as transparent to the readers as
possible.
Enjoy!
JSol
P.S. You can still send mail to <WorkS at MIT-AI>, or you can send
mail to <WorkS at Rutgers> if you prefer. Archives will continue to be
maintained at MIT-AI, and additionally at Rutgers in the <WORKS>
directory (at Rutgers, much of the WorkS archive is on tape, so if you
desire back issues you should mail your request (or any list
maintainence request) to <WorkS-Request at MIT-AI> or <Works-Request
at Rutgers>.
------------------------------
Date: 16 October 1981 1014-EDT (Friday)
From: Hank Walker at CMU-10A (C410DW60)
Subject: when are 32-bits coming
CC: dreifu at wharton-10
I assume that the MC68000 doesn't count as a 32-bit machine. Intel
has yet to ship any 432s, so it will be a while before any appear in
personal computers. A VAX takes 400 kbits or more of microcode, and
at least 500k transistors total to make even the slowest one. Even a
chip-set must be fairly complex.
The obvious thing that 32 bits gives you is a larger virtual address
space. Lots of applications are hard up against existing limits, and
must resort to memory management by hand, which is a royal pain. In
addition, 32-bit processors usually have a more complex instruction
set, addressing modes, etc, which allow them to perform better on a
wide range of tasks (ignoring the RISC arguments). Examples are
string and floating-point datatypes. The 432 includes a significant
amount of OS support, as well as provide a capability architecture.
Given the thickness of the architecture manuals, I don't know how well
this will go over.
32-bit processors usually also have a larger physcial address space.
Since 16 Mbytes and more memory will appear on personal computers in
this decade, this is an important consideration.
------------------------------
Date: 19 October 1981 18:50 edt
From: SSteinberg.SoftArts at MIT-Multics
Subject: #19 and 32 bits
The most important thing 32 bits buys is larger address space.
It was annoying to have to pass around 16 bit pseudo-pointers
on the IBM 1130 (back in '69) to address a data base larger
than 64KB and it is still annoying to have to call the
subroutine library in order to reference an item of data.
Think of 32 bits as more object names one can use in
programming.
------------------------------
Date: 20 Oct 1981 0030-PDT
From: SCHIFFMAN at SRI-KL
Subject: 32-bit micros, iAPX-432 based workstations
cc: schiffman at SRI-KL
To figure out how much an advantage a 32-bit micro would be, first
figure out what a "32-bit" micro is --
There are several things in a computer which have a `size':
1) The width of the accumulators/general-registers
(This is confusing in machines which allow concatenation
of registers like the Z8000). Wide registers gets you
shorter (faster) programs by eliminating extra `name'
references for OPERANDS WHICH REQUIRE THAT PRECISION.
Not surprisingly, 128-bit registers aren't very handy for
programs which only do byte-boffing. In fact, wide
registers HURT for programs which don't need the precision
if having narrower registers means having more of them.
The Z8000 tries to have its cake and eat it too.
2) The width of significant data paths such as the ALU.
(How many bits can you add in one microcycle?
Many machines have a N-bit ALU and an 2N-bit shifter.)
Wide data-paths make atomic operations faster for
operations which require the precision. All else being
equal, however, the wider the data path gets, the slower it
cycles (carry propagation).
3) The width of the processor/memory data interconnect.
(How many bits can you fetch in one bus cycle?)
Wide data interconnects to memory speed up operand
fetches/writes which again, helps only on operands which
need the precision. Luckily, if the instruction execution
unit is at all clever, wide memory almost ALWAYS speeds up
instruction fetches; this can be VERY significant.
Unfortunately, for small systems, cost can be almost
linearly proportional to memory bus width.
Under these criteria....
CPU Register Data Path Memory bus
Width (bits) Width (bits) Width (bits)
----------------------------------------------------------------------------
Z8000 64,32,16,8 16 16
MC68000 32 32 16
I8086 16,8 16 16
I8088 16,8 16 8
NS16000 32 32 16
iAPX-432 variable?, to 80 80? 16/user-prov.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
The table is straightforward, except for the 432. My understanding is
that the 432 has no "general-registers", really. It does have many
internal registers available at the microprogram level, at least some
of which have to be 80 bits to hold results in Intel (IEEE draft)
floating point `double-extended' format. As for the bus interface,
this is rather complicated -- the 432's Bus Interface Unit can connect
to user-designed memory systems of various types. I believe that the
Intel evaluation boards use a 16-bit memory bus. So what about the
432 is 32-ish? Only the obvious, I think.
As for its applicability in personal workstations, I think this is
pretty dubious for the next few years.
* A system including the 432 would be VERY expensive by
workstation standards, even if Intel gave the chips away
(which doesn't seem to be in their plans -- the set
currently costs on the order of a kilobuck). Besides
being very memory hungry, a realistic system requires an I/O
processing symbiont higher in complexity than most current
micro-computer systems.
* A personal workstation system based on a 432 could very
well be much SLOWER than a system based on (say) the 8086!
Sorry folks, a full context switch on every subroutine call
and a domain-check for every external reference is very
expensive. Now if you had, say, four CPU sets in your
workstation, you might very well win -- that is if all your
compute-bound programs divided into four balanced processes.
Intel seems to be saying that the 432 is intended for high-performance
shared-database transaction processing systems. I say that if it's
good for anything at all, its probably just that.
-Allan
------------------------------
Date: 18 Oct 1981 (Sunday) 1506-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: VideoDisks on Personal Workstations ?
[Note: This message originally appeared on the VideoDisk discussion
list -JSOL]
Electronic Design for Sep-30, 1981 has a full artical on video-disk
technology. Here are some highlights....
Corning has eraseable video disks using polarizers and stuff !
Medias being used include: Silver-halide, Tellurium,"Drexon Media",
bismuth, rhodium, titanium, thermodegradable/metal film.
Many are producing disks writable with semiconductor lasers (cheaper)
Formerly it took a gas laser to produce enough power.
(this is also due to improvments in laser technology)...
Bill W
<BillW at SRI-KL>
------------------------------
Date: 20 Oct 1981 1610-EDT
From: PRSPOOL at RUTGERS
Subject: MESA MANUAL
Does anyone at XEROX-PARC ( or anywhere else )
know where I can get hold of a MESA manual ( or at least
a fairly descriptive paper ). I recently noticed a
referance to the MESA LANGUAGE MANUAL by James G. Mitchell,
William Maybury and Richard Sweet of XEROX PARC, published
in February, 1978.
--Peter R. Spool
Rutgers University
------------------------------
End of WorkS Digest
*******************
-------
Subject: WORKS Digest V1 #21
∂21-Oct-81 2329 Jonathan Alan Solomon <JSol at RUTGERS> WORKS Digest V1 #21
Date: 22 Oct 1981 0103-EDT
From: Jonathan Alan Solomon <JSol at RUTGERS>
To: Works: ;
WorkS Digest Thursday, 22 Sep 1981 Volume 1 : Issue 21
Today's Topics:
Other Considerations Of 32 Bit Processors
Videodisks As Memory
----------------------------------------------------------------------
Date: 21 Oct 1981 1918-PDT
From: SCHIFFMAN at SRI-KL
Subject: Addition to processor taxonomy
In my consideration of the "32-bitness" of CPUs, I now realize that I
left out two other things that have a width:
4) The number of physical address bits presented to the
memory bus.
Obviously physical address bits cost more IC pins and
backplane wires, contributing to cost. Not so obviously,
address bits can contribute greatly to the cost of memory
management hardware (and the time cost of using it). The
point is that you don't really want to pay much more for
physical address bits than you need to address the memory
your systems will be able to afford.
5) The internal "name-space" of the architecture, i.e. log2 of
the number of unique objects that can be referenced.
The reason why we can't more simply define this
(as say, the number of bits in a `pointer') is that
some architectures can have arbitrarily complex ways
of encoding internal names, say by using the data-type
field of an op-code to provide extra "logical-address
bits".
Again, a large name space can be a mixed blessing. One of
the most important (for instruction encoding efficiency)
areas of CPU architecture is how to compress memory
requirements for expressing local names. This can be done
badly for machines with even a relatively small name space
(i.e. the PDP-11, where all offsets take 16 bits).
Under these additional criteria, the updated table...
WIDTH (Bits)
CPU Registers ALU Memory Phys. Log.
Data Addr Addr
------------------------------------------------------------
Z8000 64,32,16,8 16 16 24 24
MC68000 32 32 16 24 24
I8086 16,8 16 16 20 20
I8088 16,8 16 8 20 20
NS16000 32 32 16 24 24
iAPX-432 to 80 80? 16 24 40
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
I reread the 43203 data sheet and decided that the memory data bus
was, by the definition that I gave, not "user-supplied", but 16 bits.
The reason for this confusion is that the data bus operates in burst
mode (only one address output for the transaction) for operations on
words longer than 16 bits; this is real optimization since addresses
usually take as much as half a bus cycle.
-Allan
------------------------------
Date: 21 October 1981 2333-EDT (Wednesday)
From: Stephen.Hancock at CMU-10B
Re: Rotating Memories ("video disks")
The October issue of Mini-Micro-Systems has an artice entitled
"Rotating- memory devices move to optical reading". The article
informs us that european systems are being devoloped by Philips NV
and Thomson-CSF. The device is supposed to be a 10G bit drive with a
twelve inch platter. There are plans to have a system with a 64
platter magazine (thats 640G bits). The system is expected to be
released in about 2 years the projected OEM cost is between $2000 and
$10000 each. The article also points out the sales dollar volume and
number of optical units sold will be only a small fraction of the
total rotating memory market.
Steve
------------------------------
End of WorkS Digest
*******************
-------
Subject: WORKS Digest V1 #23
∂26-Oct-81 0011 Jonathan Alan Solomon <JSol at RUTGERS> WORKS Digest V1 #23
Date: 26 Oct 1981 0233-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WORKS at Rutgers
To: Works: ;
WorkS Digest Monday, 26 Oct 1981 Volume 1 : Issue 23
Today's Topics: Alto Snipe Revisited
Symbolics' Personal Workstation Query
----------------------------------------------------------------------
Date: 24 Oct 1981 0057-PDT
From: Chris Ryland <RYLAND at SRI-KL>
Subject: apparently random Alto snipe
To: Editor-People at SU-SCORE
I just sent an apparently snide message to Editor-People about the
Altos and their outdatedness; I realized that this might sound
off-hand or snooty, so let me clarify what I meant, and possibly start
a set of flames.
The Alto, without a doubt, was an interesting toy which gave many
bright people a teething device for their ideas about human
engineering, etc. However, I have a heretical theory that the Alto
did more to *slow down* Xerox in their mad rush for the information
systems of the future than it did to help them. Why? Because it's
far too small of a system to be anything more than a toy, in the sense
of providing enough power to support a very good programming
environment.
For example, because the Alto was so successful as a workstation
within Xerox for the past few years, everyone was saddled with them;
this included even the SDD folks, who were chartered to pull together
the PARC tinkerings into some sort of reality (the Star and its
satellites). To build even a medium-sized system in Mesa would
require hours and hours of sitting at an Alto (well, doing other
things), and thus, for things like BravoX (SDD folks out there, please
correct me if I'm wrong), building new systems would take far longer
than if some sort of time-sharing system had been around to do the
crunching needed. Only recently did the SDD folks get Dolphins, and
even these were no huge step forward. The Dorado is confined mostly
to PARC and certainly is too expensive and flakey to replace all the
Altos within the Xerox companies.
In my opinion, the only workstation worth even considering at this
point is the Lisp Machine, as purveyed by Symbolics and LMI. Even the
current generation beasts are rather underpowered for what they're
trying to do; this is supposedly being solved by the next generation
of machines (the only one in the works, as far as the public knows, is
the Symbolics 3600).
Why do I make this extravagant claim, given all the incredibly
wonderful workstations around, such as the Apollo, the PERQ, the
Wicat, the SUN? The reason is software (isn't it always), even
ignoring the pitiful hardware being touted these days as the latest,
greatest thing since sliced bread. The Lisp Machine comes with dozens
of man years of software investment, and those are years invested in
what is by far the most synergistic environment you could hope for,
given the state of technology. I would make the claim that nothing
else comes within 5% of matching that environment, though I have no
way of proving that claim. A good indicator might be a simple
anecdote about IJCAI '81: when the Three Rivers folks actually sat
down with a Lisp Machine (in a nearby booth), they were astounded (I
shouldn't put feelings in their hearts, and this was reported by a
Lisp Machine type, but I can certainly understand any astonishment,
having seen the PERQs and having worked with Lisp Machines!)
Admittedly, other people have gone long ways towards building
excellent environments (the Cedar project at PARC, and the LRG people
at PARC with their various Smalltalk systems); however, it'll be
years, if ever, before the world gets the benefit of the first, and
Smalltalk is a fairly impressive system, but still has some questions
about viability in "the real world" (for example, Smalltalk 80/81/82
still lacks multiple inheritance).
I guess what triggered this whole flame was the sight of the pitiful
systems being proposed by the real world as useful working
environments. The Xerox, IBM, HP and DEC new "personal systems" are
abject horrors (CP/M, my foot). PERQs are just beginning to get
simple operating systems with real file system support. Every 68000
incarnation in the world has its Unix lookalike, or a XENIX hovering
in the wings. I make the bold claim that NONE OF THEM has anything
interesting to offer other than, perhaps, a large screen.
End of flame.
------------------------------
Date: 5 Oct 1981 10:21 PDT
From: Fenchel.ES at PARC-MAXC
Subject: Symbolic Systems Inc. Personal Computer
Is anyone familiar with products/planned products of Symbolic
Systems Inc. (or is it Symbolic Inc.). They are based in Los
Angeles and rumor has it they are building a Lisp machine and
an Ethernet interface for it.
Any information will be appreciated.
Bob (Fenchel.es@parc)
------------------------------
End of WorkS Digest
*******************
-------
Subject: WORKS Digest V1 #24
∂27-Oct-81 0107 Jonathan Alan Solomon <JSol at RUTGERS> WORKS Digest V1 #24
Date: 27 Oct 1981 0144-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WORKS at Rutgers
To: Works: ;
WorkS Digest Tuesday, 27 Oct 1981 Volume 1 : Issue 24
Today's Topics: Xerox Altos
Symbolics LiSP Machines
----------------------------------------------------------------------
Date: 26 Oct 1981 1035-PST
From: Tom Wadlow <TAW at S1-A>
Subject: Alto Flamage
Chris Ryland claims that the Alto development and general use
held back the development of better things at Xerox. My question
is: Compared to what?? The Alto was developed around 1972,
and is clearly obsolete today. However, I would still rather
have an Alto than the fairly unintelligent terminal I work on
today. If Xerox had waited for Dolphins or Stars, their people
would be getting them right about now. With the Altos, Xerox
has had several years of *very* valuable experience in office
information systems. If they had not used Altos, chances are
that their people would have spent those years working on
80x24 character terminals and hated it, while Xerox learned nothing.
Another point. While I agree that a Lisp Machine probably provides
the best programming environment around today, an Office of the
Future is not entirely a programming environment. The Alto got
advanced office automation software into the hands of its intended
user community: secretaries and managers and other non-programmers.
And I strongly suspect that the experience gained from that move
is heavily reflected in the design of the Star. The widespread
use of the Alto was a necessary step in the development of
the current generation of Xerox products, not a hindrance.
------------------------------
Date: 26 Oct 1981 2228-PST
From: Chris Ryland <RYLAND at SRI-KL>
Subject: Symbolics; Alto snipe
Symbolics does manufacture a personal workstation; see my previous
WorkS message about the Lisp Machine. They will support Ethernet
hardware on the next version of their machine (the 3600), but it will
speak Chaosnet protocols softwarily (of course, I shouldn't prejudge
their longer-range plans about protocols; one can assume they'll
attempt to live compatibly with other Ethernet protocols via suitable
encapsulation on the 10Mhz ether). Call them in LA if you want more
info. (No, I don't get any commissions from them.)
Let me clear up my previous "Alto snipe" lest I appear completely
insane. I stated my position about the Alto somewhat provocatively,
but I didn't mean to imply that Xerox has made some huge mistake in
using the Altos extensively in-house; they never had much alternative
(I also wasn't pushing for time-sharing systems, but rather advocating
powerful servers for when you need to crunch). What I meant, rather,
was that the outside world has always been dazzled by the Altos, which
are, when you get down to it, rather "cute". However, their "punch"
is fairly minimal, and they have always lacked the kind of
comprehensive environment which makes a system such as the Lisp
Machine so attractive. For example, although various Smalltalks on
various Xerox machines (not copiers; Altos, Dolphins, Dorados) do
provide a fairly comprehensive computing environment, they've never
had an editor or a mail system in common use built-into the Smalltalk
environment. I.e., Altos and Dorados tend to be used as tiny
single-user "timesharing" systems, in which you have the usual
executive/program dichotomy. (I used Altos enough at MIT to learn to
dislike them, though they're wonderful intelligent terminals.)
On the other hand, the Lisp Machine provides a completely homogenous,
"vertically integrated" environment, in which the editor, mail system,
compiler, network file server (yes, each machine has a file server),
network file user, local file system, interpreter, window system,
etc., are completely useable at any level by any user (Lisp!) program.
The folks who built these machines at MIT (now dispersed to various
companies) spent a lot of time making the system software
comprehensive and useable.
For example, someone here wrote an Alto Draw equivalent (roughly the
same functionality, without all the bells and whistles) on the Lisp
Machine in a week of spare time hacking (mostly spent learning the
window system); in otherwords, there is a vast range of functionality
available through the system software, which is fairly easily extended
via Flavors.
This is not to say these machines are without problems. For example,
the system, as you boot it up, occupies about 5 megabytes of virtual
memory. That's fine, but clearly, you need a good deal of real memory
to make things work reasonably (1.5-2 megabytes seems to be
comfortable). And, these machines are NOT fast; no one has been able
to compare them to other machines to anyone else's satisfaction, but
there's a general feeling that they're faster than a KA-10 and 2-3
times slower than a KL-10. They don't do arithmetic very rapidly (an
integer add seems to take more than 10 usecs, for example), but this
isn't a fair yardstick for their basic speed. A lot of speedup is
promised for the Symbolics 3600, esp. in the area of function calling
and message passing.
Perhaps I can best summarize this flaming with a suspicion which only
time will bear out: to provide the kind of comprehensive computing
environment which the Lisp Machines are approaching, you're going to
need a heck of a lot of hardware power (virtual memory, microcode
space, raw microengine speed, paging disk speed, etc). And I don't
think any of the other current offerings come close. I don't mean to
say that you can thus write off all the workstations on the market,
but that you can't expect them to provide anything else than a
bare-bones world, or a fairly tightly-bundled, special-purpose
environment (such as the Star). That's sad, because the "real world"
seems to be making all the mistakes of yesteryear all over again (it
happened with micros and it'll happen many times more), instead of
starting with the best that we've got and building from there.
(I forgot to mention the Dolphins: they seem to be fairly good
Interlisp engines: Xerox EOS claims they'll be KL-10 speeds or better
after some software tuning. However, their major problem, for an
experimental environment, seems to be their lack of common bus
connectability.)
(Oh yes, though this is getting long-winded, I can't shouldn't slight
Xerox: they HAVE built a very good software development environment
for Mesa on the Dolphins and Dorados. But I don't think this'll see
the light of day for a while, if ever. And, Mesa is a compiled
language lacking more modern message-passing concepts (though I did
hear that the Star software was built with a Flavor-like package built
on Mesa), so you don't get the kind of dynamicity you would with Lisp
or Smalltalk.)
------------------------------
End of WorkS Digest
*******************
-------
Subject: WORKS Digest V1 #25
∂27-Oct-81 2304 Jonathan Alan Solomon <JSol at RUTGERS> WORKS Digest V1 #25
Date: 27 Oct 1981 2240-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WORKS at Rutgers
To: Works: ;
WorkS Digest Wednesday, 28 Oct 1981 Volume 1 : Issue 25
Today's Topics: MC68000 Paging Query
Lisp Machines: Not Everybody Likes To Program In Lisp
----------------------------------------------------------------------
Date: Friday, 23 October 1981 00:04-EDT
From: Goldberg (Robert N. Goldberg)
Re: MC68000 paging
Someone who works for a company that produces specialized computer
systems has been telling me that they decided to build their next
system around the Z8000 rather than the MC68000 because they had
serious doubts about being able to do paging on the MC68000. They
claim that there is a design problem that prevents instruction
resumption after a page fault. I understand that Apollo solves the
problem by using 2 68000 chips.
Having briefly studied the instruction set and architecture of the two
CPU's, I see the MC68000 as superior for the application of this
company (they want a large virtual address space that can be accessed
from a high level language, and speed is important), and it seems to
me that getting stuck with the funny segment addressing of the Z8000
will cause problems.
1) Is there a real problem implementing virtual demand paging on the
MC68000?
2) Can anyone tell me some of the problems one faces when generating
code from a compiler (e.g. C) for a segmented memory machine such
as the Z8000? I know that you have to do array subscripting
carefully, but what are some of the more insidious subtle problems
that come up?
Bob Goldberg
------------------------------
Date: 27 Oct 1981 15:14:19-PST
From: decvax!pur-ee!purdue!cak at Berkeley
Re: Lisp Machines
I may be called a heretic for this, but here goes. The Lisp Machine
sounds very nice...I was really excited when I first saw the
announcement. But,....
WHAT IF YOU DON'T WANT TO PROGRAM IN LISP?
I personally am not crazy about Lisp. It is good for some things, but
for most of my hacking, I prefer C (I fight with emacs because I have
to do my extensions in MLisp. I understand why, but I don't have to
like it.)
chris
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #26
∂29-Oct-81 0055 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #26
Date: 29 Oct 1981 0212-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
WorkS Digest Thursday, 29 Oct 1981 Volume 1 : Issue 26
Today's Topics: LiSP Machines - Not Just for LiSP
MC68000 Query - Answered
Hardware and Editor Technology
----------------------------------------------------------------------
Date: 28 Oct 1981 11:03:57-PST
From: ARPAVAX.ecc at Berkeley
Full-name: Eric C. Cooper
Subject: Languages and Lisp Machines
A friend at Symbolics told me that a comprehensive language project is
going on there; by the time the new machine is released, they expect
to have C, Pascal, and Fortran 77 (translated to Lisp, of course.)
Since routines in any of the languages will be mutually compatible,
they will be able to provide the same whizzy program development
environment that is already there for Lisp.
Also, in response to the question about network support, they seem
biased towards chaosnet, but may be swayed by their customers' needs.
They may even talk TCP/IP soon.
Eric Cooper (ecc@berkeley, ucbvax!ecc)
------------------------------
Date: 28 Oct 1981 1154-PST
From: Stevan Milunovic <Milunovic at SRI-KL>
Subject: C Compilers for the MC68000
cc: Milunovic at SRI-KL
I would appreciate any info on available C compilers and optimizers
for the 68000. I have heard rumors that the MIT compiler is 'better'
than Whitesmith's and would like to hear other comments. Please send
replies to milunovic@sri-kl and I will send a combined response to
Works. Thanks.
Steve...
------------------------------
Date: 28 Oct 1981 16:00:37-PST
From: ihnss!ihuxq!ihuxp!ljspot at Berkeley
Subject: MC68000 Paging Query
I have a report from John Gilmore, an independent consultant, which
has info on this problem. In brief, he states that:
1. On a page fault, the executing instruction can not in
general be identified.
2. There is no way to determine how far execution of the
instruction had progressed prior to the pafge fault.
3. Any executing instruction is aborted when a page fault
occurs due to instruction prefetch.
His report is titled "Suggested Enhancements to the Motorola MC68000"
and is 14 pages long. The report is copyrighted, but may be
reproduced if not for commercial advantage and credit for the source
is given. His address is:
431 Ashbury St
San Francisco, CA 94117
Voice: (415) 621-9355 ABBS(300 baud): (415) 863-4703
Hope this is of some use to you.
------------------------------
Date: 28 October 1981 23:55 est
From: SSteinberg.SoftArts at MIT-Multics
Subject: Lisp Machines
Luckily, LISP has a much larger semantic space than most languages so
it is much easier to imbed a C, PASCAL, FORTRAN or whatever language
you wish to program into it than the other way around. I would not be
surprised if someone hacked up a PASCAL, ADA or FORTRAN front end for
the LISP machine which just transformed the source program into LISP
program and passed it to the compiler. I am less sure that someone
would be interested in doing this for C.
------------------------------
Date: 28 Oct 1981 09:39:39-PST
From: cbosgd!mark at Berkeley
To: CSL.BKR@SU-SCORE
Subject: Re: Hardware and Editor Technology
Cc: ucbvax!editor-people@Berkeley
[Forwarded to WorkS by Henry <Dreifus at Wharton>]
The SUN sounds wonderful, if you're willing to spend $5-7K each for
them (which is reasonable in some industrial environments, but I find
it farfetched that a University would spend that kind of money on its
students for instruction) and if you don't want to work at home.
Couldn't you put a couple floppies and a modem on one of these things
and make it usable over a dialup? If you're already spending $5K,
another $1500 seems insignificant for the extra capability.
------------------------------
End of WorkS Digest
*******************
-------
Subject: WORKS Digest V1 #27
∂29-Oct-81 2312 Jonathan Alan Solomon <JSol at RUTGERS> WORKS Digest V1 #27
Date: 30 Oct 1981 0041-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WORKS at Rutgers
To: Works: ;
WorkS Digest Friday, 30 Oct 1981 Volume 1 : Issue 27
Today's Topics: More On MC68000 Paging
Lisp Machine Vs. The Alto
----------------------------------------------------------------------
Date: 28 Oct 1981 1041-PST
From: Ian H. Merritt <MERRITT at USC-ISIB>
Subject: Re: [Goldberg] MC68000 paging
To: works at RUTGERS
I have heard that the solution to the problem is simple: use 2 chips,
one for the main processor; the other for the pager. The reason that
the instructions may not be restartable is because of the way
auto-inc/auto-dec is handled. Restarting the instruction would result
in the register being modified twice. The two processor solution is
to have the page trap cause the second processor wake up, while
asserting a *LONG* wait state on the first. The second processor then
checks the error registers and determines the necessary action,
fetches the page, and clears the latch which is holding the primary
processor hostage. This, in turn, puts the secondary processor in a
wait state until another page is required.
As for the capability of the two processors... I would agree: the
MC68000 is by far the better of the two.
<>IHM<>
------------------------------
Date: 28 Oct 1981 0451-PST
From: SCHIFFMAN at SRI-KL
Subject: Paging on the 68000
cc: schiffman at SRI-KL
Yes, it is not really possible to do vanilla paging on the 68000.
It's rather cruel to think of this as a flaw in the design, since the
other microprocessors in its class have similiar problems (e.g. Z8000,
I8086).
Basically, ANY processor which has "page-faultable" instructions that
have side-effects must take heroic steps to make the instructions
re-startable. For example, auto-incrementing address modes in a
PDP-11'ish instruction:
MOVE -(R0),(R0)+
if the either of the memory references fault, you can't restart from
the top.
You can keep extra bits of "micro-state" to remember where you were
when you faulted, so that you can restart from there. In a complex
architecture, this may mean keeping "shadow-registers" or completely
saving the "micro-state" -- VERY hairy. One particularly silly way
to save the micro-state is to switch out the processor and switch
another one in to handle the page fault! (But if you didn't design
the processor you may not have had a choice). The main reason why it
loses is that you can't do anything else while waiting for the disk
page to roll in (yes Virginia, even personal machines have multiple
processes).
Alternatively, you can simplify your architecture so that instructions
that can cause a fault don't have side effects. Intel, for example,
will be using "demand-segmentation" in the iAPX286 -- the only thing
that can cause a fault is loading a segment register -- and those
instructions are simple to restart. It is also possible to just make
these restrictions by software convention (ha!).
Zilog, Intel and Motorola all claim that they will shortly have new
versions of their processors that permit restarting of memory faults.
Because of the extremely restrictive way that they address memory,
Intel will have the easiest time of it.
My estimation is that the MC68000 and the Z8000 will be about equally
difficult (for the manufacturer) to turn into a "virtual-memory"
version.
BTW, I might mention (at the risk of appearing biased) that there are
microprocessors that already handle true demand-paging:
Intel iAPX 432
National NS16000
Fairchild F9445
although all three have problems of availability!
-Allan
------------------------------
Date: 27 Oct 1981 15:37 PST
From: Deutsch at PARC-MAXC
Subject: Ryland's comments on Xerox Alto
The Lisp Machine is a much larger, MUCH more expensive system than the
Alto. Here at PARC we were quite aware of the fact that we exceeded
the Alto's capacity to do things that were interesting to us sometime
around 1976. If non-technical factors had not intervened, we would
have had Dorados (which knock the present Lisp Machine flat on its ass
in terms of hardware power, both absolute and per dollar) not long
thereafter.
The Smalltalk environment is as integrated as that of the Lisp Machine
-- more so, in my opinion, in that a much smaller part of the system
is written in any language other than ordinary user-level Smalltalk
(no subprimitives, etc.). The Lisp Machine environment offers a
larger range of features and services largely because more people
interested in programming environments per se have worked on it on
more powerful machines for a longer period of time, while the
Smalltalk builders at PARC have been concerned with other things.
------------------------------
Date: 29 October 1981 22:58 est
From: Frankston.SoftArts at MIT-Multics
Subject: Re: MC68000/Z8000 Paging Query
Reply-To: Frankston at MIT-Multics (Bob Frankston)
It is not the Z8000 itself that handles faults, but the Z8003
(formerly the Z9000) -- an updated version. Supposedly an
updated 68000 is planned. Using two processors where the
second process the fault while the first is suspended does
allow one to handle page faults on the 68000, but the page
handler must not itself take page faults -- a limitation on the
architecture of an operating system. It also means that no
other processing can be done on the main processor until the
fault is satisfied.
------------------------------
End of WorkS Digest
*******************
-------
Subject: WORKS Digest V1 #28
∂01-Nov-81 2227 Jonathan Alan Solomon <JSol at RUTGERS> WORKS Digest V1 #28
Date: 1 Nov 1981 2353-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WORKS at Rutgers
To: Works: ;
WorkS Digest Monday, 2 Nov 1981 Volume 1 : Issue 28
Today's Topics: Lisp Machine Language Support
Demand Paging On iAPX 432
Backing Out Of An Auto{inc|dec} Instruction
Symbolics 3600
Altos & Dorados & LispMs & Dolphins
Paging (Or Lack Thereof) On The MC68000
----------------------------------------------------------------------
Date: 1 November 1981 23:38-EST
From: The Moderator <JSol at Rutgers>
Subject: Administrivia
[Due to a small hardware problem, some of you received multiple
copies of Friday's digest (V1 #27), sorry -JSOL]
------------------------------
Date: 30 October 1981 01:49-EST
From: Daniel L. Weinreb <dlw at MIT-AI>
Subject: Languages and Lisp Machines
Eric Cooper is correct: Symbolics will support Pascal, Fortran 77, and
C on the 3600. This may work by actual translation into Lisp, or by
translation into an intermediate representation inside the compiler.
------------------------------
Date: 30 October 1981 0755-EDT
From: Hank Walker at CMU-10A
Subject: autoinc/dec
It isn't that hard to implement autoinc/dec. The 11/780 has an RLOG
stack containing 9 locations of 5 bits each (I think). Whenever you
do an autoinc or dec, you push the inc or dec value on the stack. On
a fault (any kind of fault), the microcode pops the stack values and
reverses the operations. I can think of lots hairy problems with
backing out of instructions than this.
------------------------------
Date: 30 Oct 1981 (Friday) 1154-EST
From: FRANKEL at HARV-10
Subject: Re: Demand paging on iAPX 432
To: Schiffman at SRI-KL
cc: FRANKEL
The intel iAPX 432 does not support any form of demand paging, but,
rather, has a fairly primitive segmentation scheme. This scheme
allows segments to either be entirely swapped in or not in memory at
all. The dual 68000 implementation allows for true demand paging with
the restrictions already enumerated. Other 68000 solutions include
restricting the instructions that a compiler will generate so that the
page fault address can be detected and the code resumed (using only
one 68000). Motorola is in the process of coming out with a new 68000
that corrects the "bus error" problem and some really minor
annoyances.
Jamie Frankel
------------------------------
Date: 31 October 1981 02:51 est
From: HGBaker.Symbolics at MIT-Multics
Subject: Symbolics 3600
36-bit machine, 2↑28 word address space (1 billion bytes)
32-bit immediate (non-consed) integers, IEEE float
instruction fetch unit
instruction + stack cache
2↑24 word physical address capability
512K words memory/card
4-5 slots for memory cards
67, 160, 300+ Mbyte winchesters
10 Mbit Ethernet
800 rows of 1000 dots B/W
1K x 1K color, 8 bits/pixel
68000 I/O controller
Multibus.
basic configuration <$60K for quantity 10.
Ethernet protocols subject to availability from Xerox Corp and
reasonableness.
------------------------------
Date: 31 Oct 1981 1019-PST
From: Chris Ryland <RYLAND at SRI-KL>
Subject: one last apologia; query for high-end users
In response to Peter Deutsch's mail, I should once more emphasize that
my initial flame was mostly in reaction to the world's tendency to
adulate the Alto; as Peter pointed out, the folks at XEROX knew long
ago that they had outgrown the machine, but I don't think that's clear
to the world at large. I didn't intend to slight XEROX. And, yes,
the Dorado certainly "whup[s his] ass" off the current Lisp Machine,
though it's a little hard to determine the relative speeds, given the
different word sizes and internal data path sizes.
Now, my query, addressed to those of you who are contemplating using
personal machines for high-end, mostly stand-alone computational
needs, i.e., AI (speech, robotics, vision), VLSI design, physics,
etc.: what is your sense about the language base you'll need for your
work? This begins to approach "theological" issues, but I still think
it's an interesting topic.
For example, my feeling (shared by some, I hope) is that the only two
languages worth considering are Lisp and Smalltalk (I'm ignoring the
idea of embedding well-known languages such as Fortran and C in a Lisp
or other environment, to support those who don't want to deal with the
host language). The Lisp Machine and the Dolphin provide two rather
distinct approaches to the environment, but both provide Lisp. The
Dolphin, running Interlisp, is "pure" Lisp in the sense that it makes
no concessions in the arena of object-oriented programming. The Lisp
Machine is heavily object-oriented, with perhaps the most flexible of
all classification schemes imaginable, Flavors. The problem I see
with this dichotomized world of Lisp and Flavors is that, though
people are hard at work turning more and more of the Lisp Machine
world into objects which are dealt with via message-passing, there
will always be the basic objects such as fixnums (integers) and conses
which aren't objects in the Flavor sense. This fundamental dichotomy
can't be good, in that it requires two different styles of programming
and thus requires some additional and perhaps needless complexity.
Of course, there are those who must use Lisp, so the Dolphin and the
Lisp Machine appear to be the only hope we've got. (The SpiceLisp
PERQ is still a question-mark, but it's hard to imagine it being as
powerful as the other two, in nearly any sense of the word "power".)
Now, Smalltalk presents us with a choice: it is certainly as capable
as Lisp, though it certainly requires a distinct approach to most
problems, and yet it is probably 1-2 years away from even beginning to
be used widely. And, it's not clear that it will enjoy the same
popularity in the research community that Lisp does (for whatever
reasons, which probably won't be technical). Further, it will
probably be 1 year at least before it is solidly up on an acceptable
machine, such as the Dolphin, Lisp Machine, or what-have-you hardware.
Can you wait for something which isn't a sure bet yet?
Yet, Smalltalk also appears to have a good chance to be widely
available on every imaginable size of machine, which can only bode
well for the availability of good software, people versed in the
language, transport- ability of research software into the "real
world" (and vice-versa), etc. For example, it is confirmedly rumored
that DEC is basing their personal VAX's system software (the SUVAX) on
Smalltalk, and this system has a rather good graphics interface. Of
course, HP, Tektronix, Apple, and DEC have been working with the
pre-release of Smalltalk for nearly a year now, so that provides
further reason to believe that it will have acceptance in the
industry.
Enough speculation. Comments?
------------------------------
Date: 31 Oct 1981 0143-PST
From: SCHIFFMAN at SRI-KL
Subject: Re: Demand paging on iAPX 432
To: FRANKEL at HARV-10
cc: schiffman at SRI-KL
The Intel iAPX 432 does not support any form of demand
paging, but, rather, has a fairly primitive segmentation
scheme. This scheme allows segments to either be entirely
swapped in or not in memory at all.
``Primitive segmentation''??
When you think about it, pages are only fixed-size segments that must
"either be entirely in memory, or not at all". Segmentation is
clearly a more "sophisticated" quantum of memory management because
objects don't come in fixed sizes. Unfortunately for computer
architecture, it is difficult to ALLOCATE memory if you don't pretend
they do.
The 432, which can have umpteen thousand segments defined at a time,
(with each one being a typed protection domain) is considerably more
sophisticated when it comes to virtual memory management than any
other microprocessor will be for a LONG time. In fact, it is more
sophisticated than [almost] ANY existing computer's memory management
architecture.
Of course, the implementation is such that only a few segment
descriptors are cached simultaneously, which leads to poor
performance.
In fact, I think that the 432 is going to suffer for a long time due
to its lack of "primitiveness".
-Allan
------------------------------
Date: 1 November 1981 02:28-EST
From: Leonard N. Foner <FONER at MIT-AI>
Subject: Paging on the MC68000
Yes, there is a definite problem with paging with the MC68000 chip.
I worked on a design team about a year ago that, among other things,
was going to implement a virtual memory system using the MC68000 as
its CPU. Among various problems we ran across (such as only ONE
interlocked instruction, when you really needed at least two) was the
problem of paging.
As it turns out, the MC68000 does not save enough state on such a
fault to be able to recover completely. It misses about two status
bits. I don't have my manual handy, and it's been a while since I
looked at this problem (the project ended about 9 months ago), but it
most definitely would not do paging right. This made it quite
difficult to come up with a robust paging system.
The general idea we came up with was that paging on the MC68000 was
easily possible if certain instructions were avoided (or, alternately,
could be guaranteed never to fault upon execution, a rather diffcult
constraint).
If people are interested, I will go back through my old design notes
and see exactly what the problem was. It was not insurmountable (since
we figured out at least one way around it, as I recall), but it was
definitely an inconvenience.
I don't know about this system with two MC68000's in it, but from the
description it sounds like they're using one chip to keep track of
state for the other... a klugy solution at best, of course, but
better than having to eliminate virtual memory as an option.
Note that, even using two processors and having one wait for the other
to handle paging, you can keep track of the most recently paged-out
pages in memoyr and so decrease your hits on disk paging. VAX/VMS,
for instance, does this. Then you can do a fast (no disk activity)
page for most faults (VMS hits almost all the time except for programs
that do a LOT of random paging, which is rare... and demand-zero
pages (i.e., fulll of zeroes because they've not been used yet) are
easy to do without any disk access). The only time the processor
waits is when a fault really has to involve the disk. Then you're
stuck, since you can't run any other processes while that happens.
Have fun. if you want more info, ask and ye shall receive...
eventually.
<LNF>
[By the way, your message in yesterday's digest appeared with a From:
field of simply Goldberg. Since I don't know where you are, this goes
to the whole list without mailing to you directly, which is somewhat
impolite of me but necessary under the circumstances. JSol: if
Goldberg is at Rutgers, please make sure that the @RUTGERS winds up on
the message...]
[Oops - that makes two apologies this digest. A record? -JSOL]
------------------------------
Date: 1 Nov 1981 (Sunday) 2224-EST
From: FRANKEL at HARV-10
Subject: Re: Demand paging on iAPX 432
To: Schiffman at SRI-KL
cc: FRANKEL
When segmentation is the only form of memory management, it must be
used for both protection and typing, and storage allocation. The
advantage of having both segmentation and paging is that there are two
distinct mechanisms to handle the two problems. It is often true that
segmentation alone is sufficient to solve both, but not always. The
problem with paging is that the context of the data areas of the
original problem is lost and the memory management unit must attempt
to ascertain the working set of pages the program is using. The
problem with segmentation is that it is often the case that only a
small section of a object is to be touched yet the whole object must
be swapped in.
In the 432, the segments are limited to 64K -- too small for many
large arrays used in various applications {This problem can be
resolved by using levels of arrays of pointers to achieve the desired
size}. On the other hand, if one would attempt to implement LISP on
the 432, one would find that there are not enough segments to allow
each dotted pair or even each list to be a separate segment.
In many respects there are a large number of existing computers with
at least as sophisticated an MMU.
The 432 is certainly a large accomplishment for microprocessors and
(except for its poor performance) should find good acceptance in the
Pascal/Ada market.
Jamie Frankel
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #29
∂02-Nov-81 2347 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #29
Date: 3 Nov 1981 0136-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
WorkS Digest Tuesday, 3 Nov 1981 Volume 1 : Issue 29
Today's Topics: Programming Languages
Dual CPU Paging Implementations
Paging Vs. Segmentation
Demand Paging On The iAPX 432
More On The Alto User's Handbook
----------------------------------------------------------------------
Date: 2 November 1981 02:51-EST
From: Daniel L. Weinreb <DLW at MIT-AI>
Subject: Programming languages
I agree that Smalltalk's uniform use of message passing for all
operations is more simple and elegant than the Lisp Machine's mixed
use of simple (non-generic) function calls and (generic) message
passing. However, I think that it would be very hard (though maybe
not impossible) to use message passing everywhere without sacrificing
a great deal of speed. In practice, it does not seem to hurt is much;
the language has function calls and it has message sends, and both do
argument-passing the same way; the only difference is that in one case
you name a function directly, and in the other you specify an object
and a message name, and the flavor system finds the function (the
"method") for you. We use function calling for simple things, and
full message passing when the modularity is interesting enough to
require the added flexibility and control that message passing gives
you.
------------------------------
Date: 2 November 1981 11:26 est
From: Sibert at MIT-Multics (W. Olin Sibert)
Subject: dual CPU paging implementations
Sender: Sibert.Multics at MIT-Multics
In the ones I'm familiar with, the implementation is very simple: the
"problem" CPU simply experiences a VERY long memory cycle (many
milliseconds) when it tries to access a page which the outboard memory
management unit sees is not in core. No state saving, or complicated
deductions about the processor status are required. The "supervisor"
CPU simply waits all the time until the MMU notifies it that it should
bring in a page, at which point it runs, does the I/O, restarts the
other CPU, and goes back to sleep.
This didn't work reliably with some early MOS microprocessors because
they couldn't stand to have the processor clock stopped for more than
about 5 milliseconds or so.
This is really a pretty cheap way to implement paging, all things
considered. The two CPUs run from the same memory, using the same bus,
and CPUs are switched by tri-state buffers. CPU chips are pretty cheap
(even 68000s), compared to total system cost.
It's true that this doesn't do "real" multitasking on page faults, but
the system can still do real multitasking on other events, like demand
disk I/O and timers.
------------------------------
Date: 2 November 1981 11:35 est
From: Sibert at MIT-Multics (W. Olin Sibert)
Subject: paging and segmentation
Sender: Sibert.Multics at MIT-Multics
Ah, but there IS a fundamental distinction between paging and
segmentation, to wit: Segmentation is a mechanism for helping the
programmer manage information, and paging is a mechanism for helping
the computer system manage information.
A computer system uses paging in order to appear to have a larger
quantity of physical memory than it was given by its manufacturer. In
systems where the virtual and physical address spaces are comparable
in size (the IBM 370, for example), this primarily manifests itself in
the ability to multiplex several processes with the appearance that
each has all the system memory available to it. In systems where the
virtual address space is much larger (such as the VAX), it also
provides the appearance of much more memory to individual processes.
Segmentation, on the other hand, is a way for programmers to treat a
single region of storage, of arbitrary size, as an object. Depending
on the implementation, these objects may see many different uses-- if
segments are cheap and plentiful, they can be used in a much more
versatile fashion.
When a system provides only one of these mechanisms, it must be
twisted to provide the facilities of both. For instance, PDP-11 and
VAX addressing is used to provide both the compartmentalization of
segmentation and the load-based memory management of paging.
Ideally, the two mechanisms should be completely independent; the
effects of paging should never be directly visible to the programmer.
This is usually not quite true; for instance, in Multics, segments are
expensive, largely because each segment must be an integral number of
pages, at 4K bytes each.
Another problem is the allocation of segments in a linear address
space: as long as the address space in which segments are allocated is
large enough, garbage collection is rare, though fragmentation will be
a problem. In a small address space, segments must be constantly moved
and compacted to get free space. This problem is eliminated (but at a
cost) by using paging to permit pages of a segment to be allocated
anywhere in memory.
Note that yet a third level of indirection can be imagined, which
would permit pieces of segments to be relocated transparently, yet
still not be a multiple of the pagesize in length, so that segments
could be allocated in pieces throughout a large linear virtual address
space, which was itself paged. This gets complicated, though, and one
must draw the line somewhere.
It would be possible, for instance, to implement an APX-432 paging
system which used a dual processor approach to give the "problem"
processor the appearance of as much actual physical memory as the chip
can address, and use a "supervisor" processor (not necessarily a 432)
to read in pages from disk when they are found to be missing. This
would let the 432 programmer use segments with wild and gay abandon,
never explicitly reading them in.
------------------------------
Date: 2 November 1981 20:25 est
From: Frankston.SoftArts at MIT-Multics
Subject: Re: Demand paging on iAPX 432
Reply-To: Frankston at MIT-Multics (Bob Frankston)
cc: SCHIFFMAN at SRI-KL, FRANKEL at Harv-10,
schiffman at SRI-KL
Paging ↑= Segmentation
Segmentation is address space management technique, though it is often
treated as a second level of paging.
Paging is a memory management technique used by the system, though
some systems are not careful about layering and let it show through to
the users.
Guess we need new words to avoid confusion not only due to word
inflation but architectures like the IBM /38 and probably the iAPX 432
which do not make sharp distinctions.
------------------------------
Date: 2 Nov 1981 14:42 PST
From: Taft at PARC-MAXC
Subject: Re: The Alto User's Handbook
In-reply-to: FURUTA's message of 23 Oct 1981 1607-PDT
To: Richard Furuta <FURUTA at WASHINGTON>
cc: jeff at WASHINGTON, Dake, Swinehart, Lampson, Taylor, Taft
Your message announcing the availability of the Alto User's Handbook
received rather wide distribution (for example, I believe it appeared
in the WorkS digest). I would appreciate it if you would convey the
following clarification to Editor-people and any other lists you know
about to which your original message was distributed.
While the Alto User's Handbook has indeed been cleared for
distribution outside Xerox, it has not been brought out as a PARC
external report. Our present supply of Handbooks is limited, and we
do not have the resources to satisfy the large demand that would be
generated by a public release.
Our past practice has been to sell Handbooks, at cost, to
organizations that have Altos (principally at CMU, MIT, Stanford, and
University of Rochester). But even this is ending, since we are no
longer actively developing or maintaining Alto software at PARC;
consequently, we are unlikely to reprint the Handbook again.
People who do not have Altos may be interested in more general
technical reports on the Alto and Alto-based software, available in
the open literature. The most comprehensive report on the
architecture of the Alto itself is "Alto: a personal computer", which
appears in the recently-published second edition of "Computer
Structures: Principles and Examples", edited by Siewiorek, Bell, and
Newell (McGraw-Hill). Additional good sources of papers relating to
the Alto and follow-on machines include the last two years' SOSP
proceedings and several issues of CACM.
We have published a number of PARC external reports on Alto-based
systems. These are available on request, though again we are unable
to satisfy an enormous demand. Many university and company libraries
subscribe to the PARC report series, so you may be able to find copies
in your library.
Ed Taft
Computer Science Laboratory, Xerox PARC
------------------------------
Date: 2 Nov 81 22:09:31-EDT (Mon)
From: Michael Muuss <mike.bmd70@BRL>
Subject: Re: WORKS Digest V1 #28
JSol -
I keep hearing about Smalltalk. Is there a good blurb online,
or something in the recent press that I can sneak a peek at? Seems
like there are enough enthusiasts out there, but it's new to me...
-Mike
[Don't look at me, I don't know much about it (except that it has been
discussed on WorkS). You are invited to peruse the WorkS archives at
MIT-AI, in DUFFEY;WORKS ARCHIV, or at Rutgers, in the <WorkS>
directory -JSOL]
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #30
∂04-Nov-81 0136 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #30
Date: 4 Nov 1981 0159-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
WorkS Digest Wednesday, 4 Nov 1981 Volume 1 : Issue 30
Today's Topics: Programming for Personal WorkStations
Smalltalk Info - BYTE Magazine
----------------------------------------------------------------------
Date: 3 Nov 1981 (Tuesday) 0910-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Programming for Personal Workstations
Are the techniques that will be used for programming personal
workstations going to be different to those of current scale
implementations?
How will one program workstations? Will it be easier? Will there
be other proceedures than those of large systems or simply a
reduced scale of large system design?
Hank
------------------------------
Date: 3 Nov 1981 (Tuesday) 2058-EST
From: KENDALL at HARV-10
Subject: Smalltalk info source, 432/Smalltalk juxtaposition
To: mike.bmd70 at BRL-, WorkS at RUTGER-
cc: KENDALL
The excellent August (July?) issue of \Byte\ was dedicated to Smalltalk,
written completely by members of the Smalltalk development group. This
is the best source of information about Smalltalk until the two books
come out.
If I remember correctly from that issue, the old Smalltalk virtual
memory system (called OOZE) allowed as many as 64K objects, but that
limit was reached, so the new system allows more than 64K objects.
This means that the Intel iAPX [what do those letters stand for?] 432,
which allows no more than 64K objects, would make a bad Smalltalk
engine.
-- Sam Kendall
[Thanks also to Ian H. <Merritt at USC-ISIB>, <TonyWest at PARC-MAXC>,
Steve Bellovin, Ed Pattermann <G.ECP at UTEXAS-20>, Chris <Ryland at
SRI-KL>, Jeff Prothero <JSP at Washington>, Ron Fowler <rgf at BRL>,
<Sternlight at USC-ECL>, Hank Walker at CMU-10A and Bob <Hyman at
DEC-Marlboro> for also pointing to the BYTE issue. -JSOL]
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #31
∂05-Nov-81 0835 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #31
Date: 5 Nov 1981 0456-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
WorkS Digest Thursday, 5 Nov 1981 Volume 1 : Issue 31
Today's Topics: More On Smalltalk
Programming Personal Workstations
Smalltalk, Paging/mmu on the 432
----------------------------------------------------------------------
From: Chris Ryland <RYLAND at SRI-KL>
Re: Smalltalk info
Peter Deutsch is probably the best person to reply to the query about
Smalltalk, but here's something: Smalltalk-80, the only Smalltalk to
make it out of Xerox, will be available sometime around the end of the
year. Adele Goldberg's group, (formerly?) called the Learning
Research Group, is going to publish "the book", which will tell you
all about the language, styles of use, etc., as well as the
nitty-gritty of what it takes to bring up the system (via a virtual
machine) on your favorite hardware; and, they'll license "the tape" to
organizations, said tape containing the "virtual image" and all the
system sources. With that tape, and the book, you can bring up
Smalltalk in its full glory by merely implementing the virtual
machine.
The big question at this point is how the tape licensing goes.
There'll be no problem or real expense for universities, of course,
but commercial firms will have to negotatiate with Xerox lawyers
according to their intended use of Smalltalk (e.g., for internal use
only, or for resale).
Adele may want to say something over this medium to clear up any
confusions, but, then again, we might as well wait the couple of
months it still seems to be before the book is published and the
licensing arrangements announced.
(There are said to be pirate copies of the book floating around, but
they're useless at this point, in any case, as they're rather out of
date. This is by hearsay.)
------------------------------
Date: 4-Nov-81 11:26:04 PST (Wednesday)
From: Hamilton.ES at PARC-MAXC
Subject: Re: Programming for Personal Workstations
Reply-To: Hamilton.ES @ PARC-MAXC
cc: DREIFU at WHARTON-10 (Henry Dreifus), Hamilton.ES
"Reduced scale" my eye! Over a thousand man-months and a
quarter-million lines of Mesa have gone into Star, with roughly thirty
programmers going at it for roughly three years. And that doesn't
include the underlying Pilot/ Mesa/ Communications stuff, which would
add another 50 to 100 %. I don't know how that compares with OS/ 360,
but it certainly qualifies as a large system. And one can imagine all
sorts of applications built on top of Star or similar workstations
(data base, information retrieval, realtime data acquisition and
analysis, ...) that would be of a similar scale. In fact, almost any
application more sophisticated than running the payroll is probably
amenable to a distributed implementation.
--Bruce
------------------------------
Date: 4 Nov 1981 1139-PST
From: Rubin at SRI-KL
Subject: Smalltalk on the 432
cc: kendall at HARV-10
Actually, the iAPX 432 would make a very good Smalltalk engine. It
supports 16M segments, not 64K, so object address space is not a
problem (64K is the size limit for any one segment -- probably not a
problem for Smalltalk, but a big limitation otherwise). The 432's big
win for Smalltalk would undoubtedly be its fancy context switching
(with dynamic memory allocation, even!) and hardware support of typed
domains. Since domain objects can be linked into complexes, the 432
also lets you realize the Smalltalk concepts of classes and instances
almost at the hardware level.
People seem to think the 432 will be really slow, but I'd be
interested to know if Intel has got any benchmarks yet. Based on
their initial literature, the 432 looks about as fast as a mid-range
mini for typical stuff, but it is faster than probably anything else
if you look at its operating system primitives (e.g., send message is
80 microsecs, and their send primitive is fancy). Of course, the
question is whether those primitives are useful as they stand, or
whether you need to crust a lot of software around them to get a
decent kernel. If not, response time and throughput at the
application level should be quite high (except for number crunching)
because of the incredibly low OS overhead.
By the way, my guess for the iAPX acronomym is: i -- Intel, A --
Advanced, P -- Processor, X -- makes it sound scientific (or maybe the
X stands for *, in other words, multiprocessing).
--Darryl
------------------------------
Date: 4 Nov 1981 20:31:41-PST
From: ARPAVAX.hickman at Berkeley
Subject: paging/mmu on 432
1) As for the 432 segmentation setup being too small, that is what
Prime uses for their segments, and it works just fine. As for
arrays that are larger than 64k, lifes tough all over, isn't it?
2) The nastiest page fault problems come not from auto{inc,dec}rement
stuff, but from instructions which modify memory/registers in a non
un-doable way...That is, the AND/OR type instructions....Apparently
(I am told) on the 68000 it IS possible (using the 2 chip) scheme
AND limiting the instrucitons generated by the compilers (and
assemblers, for good measure). This scheme is used in the Micro Da
Sys 68000 system and works fine...
3) If I can buy a personal computer that runs virtual vax unix on a
68000, even with the pageing brain damage, I'll take it.
kipp
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #32
∂06-Nov-81 0417 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #32
Date: 6 Nov 1981 0631-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
WorkS Digest Friday, 6 Nov 1981 Volume 1 : Issue 32
Today's Topics: Apollo Domain Systems
Software Engineering - OS/370 vs. Star
Laurel Manual Available
Fewer Programmers On Tomorrow's WorkStation
System 38 - Description Query
----------------------------------------------------------------------
Date: 5 Nov 1981 0544-MST
From: Griss at UTAH-20 (Martin.Griss)
Subject: Re: WorkS Digest V1 #31
I might comment that the Apollo Domain systems are 68000 based, do use
the 2 68000 hack to provide the VM. They run a multiprocess OS,
somewhat UNIX(tm) like; one can get about 5-9Mb per process. The
machines also communicate very smoothly across a Ring network, and our
experience with the OS, VM and network is very positive. We run their
PASCAL and FORTRAN, use some ASM too. There is likely to be a C, a
"eunice-like" system, and maybe even a full V7 Unix.
------------------------------
Date: 5 Nov 1981 0940-PST
From: Jim Archer <CSL.SUN.ARCHER at SU-SCORE>
Subject: Why would anyone want to use OS/360 as an example?
To: Hamilton.ES at PARC-MAXC
I believe OS/360 passed 3 man-millenia somewhere in the early 1970's.
Given the general relationship between total effort and the quality of
the final product, pointing out that Star may have taken 200 man-years
tends to make me suspicious rather than confident.
Jim
------------------------------
Date: 5-Nov-81 11:46:35 PST (Thursday)
From: Hamilton.ES at PARC-MAXC
Subject: Re: Why would anyone want to use OS/360 as an example?
To: Jim Archer <CSL.SUN.ARCHER at SU-SCORE>
Reply-To: Hamilton.ES @ PARC-MAXC
Before you get too "suspicious rather than confident" regarding Star,
let me remind you that the project started some four or five years ago
from ground zero -- all new hardware, microcode, network protocols,
etc. Permit me to recommend Hugh Lauer's paper, "Observations on the
Development of an Operating System" (which discusses the development
of the Pilot operating system kernel underlying Star and the other
Xerox 8000 series Ethernet products), to be published in the
proceedings of the ACM/ SIGOPS 8th Symposium on Operating System
Principles next month. Lauer's thesis is that every major new
operating system takes around five clock years and dozens of man-years
to move from conception to maturity.
--Bruce
------------------------------
Date: 5 Nov 1981 1204-PST
From: Rubin at SRI-KL
Subject: Star vs OS/360 manpower
To: hamilton.es at PARC-MAXC
If a 1,000 man months gets you a Star, then OS/360 should have been a
universe. That system took 20,000, according to what I have heard.
Excuse me, that's 20,000 man years. If you like comparisons, I
believe it took the Egyptians about 20,000 man years to build the
Great Pyramid at Cheops. In fact, the architecture of OS and its
descendants rather reminds one of the Great Pyramid (not that I'm
trying to compare IBM to pharaoh).
Who knows, it may even last as long.
--Darryl
------------------------------
Date: 5 Nov 1981 11:17 PST
From: Taft at PARC-MAXC
Subject: Laurel manual available
cc: Dake at PARC-MAXC, Taft at PARC-MAXC
Those of you who wanted to obtain Alto User's Handbooks may be
interested to know that an expanded version of the Laurel Manual,
which constituted one section of the Handbook, has recently been
brought out as a PARC report. The abstract is reproduced below. If
you would like a copy, please send a message to Sara Dake
<Dake@PARC-MAXC>.
Laurel is a user interface to an electronic mail system.
Complementing it is a mail transport mechanism called Grapevine, which
maintains a distributed data base to deal with naming, authentication,
distribution lists, and mailbox location. A paper on Grapevine will
be presented at next month's SOSP.
Ed Taft
-------------------
Laurel Manual
by Douglas K. Brotz
Abstract: Laurel is an Alto-based, display-oriented computer mail
system interface. It provides facilities to retrieve mail and present
it for delivery, and to display, forward, classify, file, edit, and
print messages. Additional features include facilities to read,
write, and copy files, run programs, and a whole lot more. Laurel is
a component of a distributed message system that has been in operation
for several years in the Xerox Research Internet.
This document is a description of the facilities contained in Laurel.
Several tips on proper use of computer mail facilities in a social
context are included.
------------------------------
Date: 5 November 1981 18:57 est
From: SSteinberg.SoftArts at MIT-Multics
Subject: New programming styles on Work Stations.
I think that the largest single difference will be the
relatively smaller number of programmers at the level we
traditionally consider programming. Instead of 3% or 25% of
all people who use a system programming it at the bit or
language level only .1% or .03% will be doing this on the Work
Station of the future. How many people double clutch anymore?
A much larger group will still consider itself programmers
although they will be dealing with constraint oriented systems
such as DNA sequencers, VisiCalc, simulation systems, Star and
so on. While many old time bit shovelers won't consider this
programming it will be considered so by most people.
The quantities of (what is now called) programming which will
go into these systems will be immense, but the dividends will
be equally large. My feeling is that a lot of those early
computer pioneer predictions will come to pass in the next few
years.
------------------------------
Date: 5 November 1981 18:53 est
From: Frankston.SoftArts at MIT-Multics
Subject: Re: paging/mmu on 432
Reply-To: Frankston at MIT-Multics (Bob Frankston)
To: ARPAVAX.hickman at UCB-C70
Prime allows segments to be concatenated. This allows arrays >64K,
but does seem to miss the point of segments as independent objects.
------------------------------
Date: 5 November 1981 16:18-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject: System 38
Is there any information available on the detailed structure of the
IBM System 38?
Stavros Macrakis
Harvard
------------------------------
End of WorkS Digest
*******************
-------
Subject: Works Digest V1 #33
∂07-Nov-81 1423 Jonathan Alan Solomon <JSol at RUTGERS> Works Digest V1 #33
Date: 7 Nov 1981 1631-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: Works at Rutgers
To: Works: ;
WorkS Digest Saturday, 7 Nov 1981 Volume 1 : Issue 33
Today's Topics: Smalltalk Usefulness
Information on IBM System 38
WorkStation Languages
TI 16-Bit Chip
----------------------------------------------------------------------
Date: 6 Nov 1981 09:09 PST
From: TonyWest at PARC-MAXC
Subject: How to get IBM System/38 Documentation
To: Stavros M. Macrakis <MACRAK at MIT-MC>
cc: TonyWest at PARC-MAXC
About finding out more technical information on the IBM System 38:
There was a nice collection of technical papers published by IBM in
1978. You might try to get hold of it:
"IBM System/38 Technical Developments" published by IBM GSD (then)
publication order number G580-0237
However - I think this report is out of print, in which case, what I
recommend is that you call an IBM branch office, tell them about this
report and what you want, and ask them to look up for you the list of
publications available for the S/38 (which has since been announced,
so there is plenty available about it). All Branch offices have a
list of publications and can order them for you (though you may have
to produce some money sometime for the books).
Tony West
Computer Science Laboratory
Xerox PARC
------------------------------
Date: 5 Nov 1981 01:07:49-PST
From: decvax!ittvax!cox at Berkeley
Subject: Suitable workstation languages?
Being of the Evolutionary, rather than Revolutionary, school of
thought I've been concerned over means for experimenting with a
language like Smalltalk on a UNIX (i.e. READILY portable TODAY) base.
The approach so far has been to use the C compiler as an "assembly
language" for a virtual Smalltalk machine; i.e. to develop a Smalltalk
compiler that produces C language as output, and then bootstrap from
this to versions that bring up more and more of the stuff that UNIX
doesn't help with (automatic garbage collection, incremental
compilation, etc, etc.).
The part that works so far is as follows: a C precompiler (of the
lex/yacc school) reads a language close to C, and turns that into C
language containing data initialization statements that define class
relationships, in a manner as close to Smalltalk as I can glean from
the available information. So with this one can experiment with
programming in objects, classes and messaging, although the input
syntax isn't Smalltalk 81 and most of the Smalltalk 81 environment is
also missing.
The next step isn't working yet, but should be soon, which is to
complete a (non-incremental) compiler for Smalltalk 81 syntax, which
uses primitives generated from the step above for data storage.
This compiler generates interpreted code, for which an interpreter
will be written (in preprocessed C).
Subsequent steps can also be envisioned, but I'll probably stop
this approach well short of "Complete Smalltalk on UNIX".
Any interest out there?
------------------------------
Date: 6 Nov 1981 (Friday) 1236-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Can smalltalk work ?
Technology wise we will probably see an S-machine, microcoded to do
the byte-code operations very efficiently.
Will the 'programmers of tomorrow' use this concept in programming
versus classical PASCAL/Fortran/ . . . styles ?
Hank
------------------------------
From: decvax!duke!unc!smb at Berkeley
In-real-life: Steven M. Bellovin
Subject: Size of OS/360
In "The Mythical Man-Month", Fred Brooks estimates that over 5000
man-YEARS went into OS/360 between 1963 and 1966.
------------------------------
Date: 5 Nov 1981 09:05:36-PST
From: decvax!duke!unc!smb at Berkeley
In-real-life: Steven M. Bellovin
Location: University of North Carolina at Chapel Hill
Subject: TI 16-bit chip
TI introduced a 24-MHz TMS99000 MPU, with a $65 price in 100-piece
quantities. (Quotes from the Nov. 2nd Electronic News).
It includes an "on-chip macrostore memory with 1K bytes of ROM and 3K
bytes or RAM for storage of frequently-used functions which can then
be accessed at full processor speeds." The company is preparing a
chip version using that macrostore for floating point operations, and
said that part, designated the TMS99110, would be available in
December at $99. The instruction set is a superset of the TMS9995 and
TMS9900, with object code compatibility. There are also new
instructions for multiprecision arithmetic, stack operations, parallel
I/O, and memory bit manipulation. It has "an instantaneous address
reach of 256K bytes of main memory and 120K bytes of internal and/or
external macrostore memory", as well as compatibility with the
TIM99610 memory mapper for control of address space up to 16M bytes.
------------------------------
End of WorkS Digest
*******************
-------
Subject: WorkS Digest V1 #34
∂11-Nov-81 0224 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #34
Date: 11 Nov 1981 0156-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
To: Works: ;
WorkS Digest Wednesday, 11 Nov 1981 Volume 1 : Issue 34
Today's Topics: Small Operating Systems
Portable SmallTalk System
Query - Real Experiences
S-Machine
Programming For The Future
----------------------------------------------------------------------
Date: 9 November 1981 0756-EST (Monday)
From: Hank Walker at CMU-10A (C410DW60)
Subject: more on VMS
When VMS was first being written, they had a goal to fit it into
64Kbytes. Since current versions lock 800-1000 pages to VMS, they
have obviously gone way beyond this. But the size constraint may be
an additional reason to scrimp on the user interface. Someone now
stand up and say that UNIX is small. Yes, but its user interface is
no better, and VMS provides more capabilities.
[There is also a discussion of VMS's user interface in HUMAN-NETS.
I would suggest that you address any further discussion on that
particular topic to HUMAN-NETS@AI -JSOL]
------------------------------
Date: 9 November 1981 1537-EST (Monday)
From: Mark.Tucker at CMU-10A
Subject: Portable Smalltalk System
Message-Id: <09Nov81 153741 MT71@CMU-10A>
The best way to obtain a portable Smalltalk system would be to code
the Smalltalk virtual machine in some suitable algorithmic language: C
would be fine. Then, get the rest of the environment by importing the
Smalltalk virtual image from PARC. By maintaining compatibility with
the Virtual Machine, all software developed under the portable system
would be valid when the a personal S-machine is eventually perched by
our desks.
Even though Xerox expects the Smalltalk virtual machine to be
microcoded, most implementations will face similiar problems detailing
the way the VM maintains data structures in a byte-aligned memory
space. A well written HLL VM implementation would serve as a
guideline for microcode writers. Perhaps,like Xerox did with BCPL on
the Alto, these HLL procedures could be subsumed into microcode as
time and microstore space would allow.
Finally, I think we want the underlying power of Smalltalk to be
available in some measure on standard 24x80 CRTs. I know this is
blasphemey, but it will be a very long time before you have a bit-map
system at home and at work. So we should start today to consider how
we will have to limit the amount of information contained by a
Smalltalk display so that it will fit in 2K characters. About the
only display format a "portable" Smalltalk system could provide would
be such a restricted, 24x80 one.
------------------------------
Date: Monday, 9 November 1981 21:13-PST
From: WANCHO at DARCOM-KA
Cc: WANCHO at DARCOM-KA, ARMTE at OFFICE-8
Subject: Real World Decisions
It seems that the current discussion, though very interesting, has
gone astray from what we have to consider as today's real problems in
selecting a workstation configuration of modest cost.
At the risk of provoking wild flaming (or utter silence), we would
like to solicit some opinions/advice on the situation we are faced
with right now:
We need to gather some hard experiences with small 4-6 user 8 or
16-bit micros of the Z80 CP/M-based or LSI 11/23/24 varieties,
respectively. These systems are to be used in an environment which
will crudely communicate in a batch fashion to send and receive mail
from a central site. We have plenty of experience with a
multi-processor CP/M system, and we have all of the correspondence of
the recent UNIX vs. CP/M discussion. What we don't have is any
experience with RT-11 that one user is strongly pushing with seemingly
convincing arguments to the novice potential user.
One of his major points is that there is a large amount of free
software available to run on it. There is also a large amount of
software already designed to interface with VT-52-like terminals.
What is not certain is the availability of a decent word processor...
Our concerns are mainly centered around our bias to the
speed/response-time advantage obtained by using a multi-processor over
the small-scale timesharing of something like an LSI 11 running RT-11.
Secondly, we need to know what compiler are available besides FORTRAN
and COBOL. Pascal, C are two others that come to mind.
Now I know that the machines discussed appear to be a step backward in
the high technology discussions carried on here, but we need to know
alot about a cost-effective approach without getting trapped in either
an obsolete technology or a flashy new one which may not get off the
ground.
Please be sure to include ARMTE@OFFICE-8 in your replies.
Thanks,
Frank
------------------------------
Date: 10 Nov 1981 (Tuesday) 1706-EST
From: KENDALL at HARV-10
Subject: S-machine
cc: KENDALL at HARV-10, Dreifus at Wharton-10
Re Dreifus's speculation on the "S-machine": the Xerox workstations
ARE microprogrammed to fit the language being used. There are
"Smalltalk bytecodes" and "Mesa bytecodes", and probably many others,
implemented in microcode.
-- Sam
------------------------------
Date: 10 Nov 1981 (Tuesday) 1707-EST
From: KENDALL at HARV-10
Subject: Programming of the future?
cc: KENDALL at HARV-10
This is in response to Dreifus's question on the programming of future
workstations, and SSteinberg's letter "New programming styles on Work
Stations".
I found the question too vague even as a topic for speculation.
SStenberg's response was somewhat specific, but contained no
arguments, only naked speculation. Furthermore, it did not specify
whose workstations it meant; and neither did Driefus's question.
This implies a belief that all workstations will share the advances in
programming of today and the future. Surely no one would argue that
most current computers are even close to the state-of-the-art, in
programming environments or languages; they use something like OS/360
and COBOL. But workstations are surely at the forefront of
innovation-- the existence of this digest implies it.
And so Xerox is. But although they have had their Altos for ten
years, the only commercial product to come out of that line of
research has been the Star, which is a word processor (a great one, to
be sure) and office filing system, not a full programming workstation.
Perhaps most work- stations will be like the Star, running slick
special-purpose packages, as SSteinberg suggests. But I fear that
Apollo-like stations will be dominant.
My purpose here is not to insult the Apollo. Apollo, Inc. itself
projects that 95% of its sales will be to engineering firms and such
using FORTRAN; this type of customer does not appreciate or want
programming innovations. The Apollo programming environment is very
primitive--indeed, the Apollo system programmers had never seen a
Xerox workstation when they wrote the Apollo software. Note also that
the Apollo is the most sophisticated general-purpose workstation
commer- cially available.
To summarize, I see the possibility for widespread better "programming
of the future", but I fear that the mistakes of the past will continue
to be perpetuated; and I see evidence for this perpetuation.
-- Sam
------------------------------
End of WorkS Digest
*******************
-------
∂15-Nov-81 2021 AVB WorkS Digest V1 #35
∂15-Nov-81 0139 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #35
Date: 15 Nov 1981 0339-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
Subject: WorkS Digest V1 #35
To: Works: ;
WorkS Digest Sunday, 15 Nov 1981 Volume 1 : Issue 35
Today's Topics: RT-11 Pascal & C Compilers - Reply
Programming Environments - FORTH , Smalltalk
Apple's Lisa Project
Integrated Office Automation & Manufacturers
Portable Smalltalk Compiler in C
WorkStations For Programmers Vs. Users
----------------------------------------------------------------------
Date: 11 Nov 1981 (Wednesday) 0528-EST
From: KENDALL at HARV-10
Subject: Inquiry on RT-11 PASCAL and C compilers
To: armte at OFFICE-1
Whitesmith, which frequently has advertisements in \Byte\, sells
PASCAL and C compilers for RT-11.
-- Sam
------------------------------
Date: 12 Nov 1981 1628-PST
Sender: BILLW at SRI-KL
Subject: Programming environments....
From: William "Chops" Westfield <BillW@SRI-KL>
Just what distinguishes a programming environment from an ordinary
operating system with its utilities ? (I think I can tell the
difference, but Im looking for formal definitions here...).
What are the currently available environments ? If I had to guess,
Id say:
Smalltalk (well, not yet really available)
Forth
and maybe
UCSD P system
Unix
Are there others ?
Bill W
------------------------------
Date: 13 Nov 1981 1503-PST
From: Gene Autrey-Hunley <Autrey-Hunley at SRI-KL>
Subject: Apple's Lisa
cc: AUTREY-HUNLEY at SRI-KL
The Wall Street Journal (11 Nov. 1981) contains the following on page
18.
"Now that the Apple III is returning to the marketplace, the company
plans to turn its focus to the strategic new products under
development, one of which has been code-named 'Lisa.' 'You are
looking at the most sophisticated and powerful graphics-editing
machine in the history of mankind,' says Mr. Jobs as he puts Lisa
through it paces. Lisa, which may become Apple IV, is a computer
aimed at the office market. It has data- and word-processing
functions, as well as a program that permits novices to create charts
and other graphics. It cost $30 million to develop."
The comment about Lisa being "the most sophisticated and powerful
graphics- editing machine in the history of mankind" sounds like hype.
But does anyone have any more substantial information about Lisa?
Could it possibly be a Smalltalk machine?
--Gene
------------------------------
Date: 13 November 1981 23:58-EST
From: Steven T. Kirsch <SK at MIT-MC>
Subject: Manufacturers and integrated OA
Does anyone know of a vendor other than Xerox that is involved in the
design of an integrated OA system (at the user/application level)
that will win?
Some manufacturers are only investigating distributed system issues
(Ollivetti, NBI) or are only looking at hardware and language issues
(BNR). HP Labs seems to be ignoring "office" automation in favor of
expert systems for the engineer which is contrary to statements from
the president of HP about HP's role in the office. Wang probably
won't have a well integrated system for historical reasons (it will be
messy underneath, I suspect). IBM lost de Jong and the San Jose folks
don't really have the right tools or background. InterActive doesn't
have a uniform user interface; they just have a lot of tools that can
be combined (Unix approach). ROLM has a uniform user and program
interface, but their implementation strategy will lose due to lack of
cycles.
With the size of the OA market, you might think there might be ONE
company that is exploring future integrated office system design on a
suitable tool (e.g., LISP machine or reasonable facsimile). But other
than Xerox, I can't think of one.
------------------------------
Date: 14 November 1981 09:49-EST
From: Daniel L. Weinreb <dlw at MIT-AI>
Subject: Portable Smalltalk kernel in C
In reply to Mark.Tucker@CMUA: The idea of a portable Smalltalk kernel
in C sounds good superficially, but you should keep in mind that only
some of the kernel can be done this way. As I understand the division
of the Smalltalk-80 system between its kernel and the rest of the
system, I surmise two kinds of things reside in the kernel. The first
kind of things are operating-system or environment-dependent things;
for example, every kernel must implement a primitive that implements a
real-time interval-timer facility, that signals a given semaphore at a
given time in the future. Things like this can't be portably
implemented in C because they depend on the environment in which the C
implementation resides: either the operating system (if any) or the
hardware (if there's nothing corresponding to an operating system).
Access to the bit-mapped display and other I/O devices is likewise
dependent system-dependent, and the parts that don't depend on the
operating system or hardware are probably in Smalltalk code rather
than in the kernel. The second kind of things are those that have to
run very quickly, and indeed you might benefit by writing those once
in C and attempting to make the C code portable. I don't know how
much of the kernel makes up the first kind of things and how much the
second kind; perhaps there is a Xerox person around who can comment?
------------------------------
Date: 14 November 1981 10:02-EST
From: Daniel L. Weinreb <dlw at MIT-AI>
In reply to Sam Kendall: I think you can rest assured that systems
like the Apollo will not be dominant among workstation-class
computers. The reason is that there is a much larger market for slick
packaged applications than there is for program development systems.
This, in turn, is because there are not that many program developers
in the world, but there are a whole lot of secretaries,
businesspeople, accountants, engineers, car designers, fashion
designers, musicians, film-makers, and so on, all of whom might
someday benefit from neat computer-based applications. SSteinberg is
in a good position to know: he is the author of the 8080 version of
VisiCalc, a particularly slick, useful, cheap, and well-implemented
application that is rightly selling very well. His company, Software
Arts, is a leader in the field of slick application packages running
on cheap computers for the mass market, and I think they stand to do
extremely well.
Now, among those workstations that will be marketed for program
development, it is possible that Apollo-like systems will be dominant.
I, too, sometimes complain that their software is backward and
primitive. But at other times, I reflect on how advanced and easy to
use and modern it is. It depends on my mood. If you compare Apollos
to all the good ideas I've seen on Lisp Machines and on various Xerox
PARC systems, they may look backward, but compared to what most people
in the world are using (not only on IBM batch systems but on Data
General time sharing systems and other things of that ilk), it's not
so bad. One can do worse than copying Unix. And the window system on
the Apollo is not half-bad; if they put in a graphical input device it
would be quite good by today's standards.
Also, you are mistaken in your assertion that the Star is the only
machine to have been marketed by Xerox that was based on the Alto
ideas. The Xerox 1100 Scientific Information Processor, or whatever
the external marketing name is, is also on the market. It is known
internally as the Dolphin, and it is a real program-development system
for the Interlisp-D system. By anyone's standards, its user interface
is up to the state of the art and is one of the best things around.
(I'm not comparing it to other things in its class so much as
comparing to to the rest of the world. There isn't very much in its
class, anyway.) You can buy them from Xerox Electro-Optical Systems
(EOS).
------------------------------
End of WorkS Digest
*******************
-------
∂16-Nov-81 0904 AVB WorkS Digest V1 #36
∂16-Nov-81 0152 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #36
Date: 16 Nov 1981 0320-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
Subject: WorkS Digest V1 #36
To: Works: ;
WorkS Digest Monday, 16 Nov 1981 Volume 1 : Issue 36
Today's Topics: C Compilers Available From DECUS
WorkStations for Programmers Vs. Users
More On The "Lisa" Project
----------------------------------------------------------------------
Date: 15 November 1981 0309-EST
From: The Moderator <JSol at Rutgers>
Subject: WorkS Archives
The WorkS Archives are kept in two places. The traditional place for
digest archives is at MIT-AI in the file DUFFEY;←DATA← WORKS. A copy
of the archives are also kept at Rutgers, however all but the most
recent issues are offline. Due to MIT-AI's recent disk problems, the
archives were not accessable from MIT-AI, so I retrieved the entire
archive from backup tapes at Rutgers.
Now that the disk problems seem to be cleared up at MIT-AI, I am
deleting the offline files from the WorkS Archive at Rutgers. If you
have need for the files on Rutgers for any reason, then please send
mail to WorkS-Request@MIT-AI and I will retrieve them from tape again.
MTFBWY,
JSol
------------------------------
Date: 15 November 1981 0216-PST (Sunday)
From: lauren at UCLA-Security (Lauren Weinstein)
Subject: C compilers
To: WORKS at AI
There is a fairly full C compiler in the DECUS library. I'm not
sure whether it is oriented towards RT-11, RSX-11, or both...
--Lauren--
P.S. It's free.
--LW--
------------------------------
Date: 15 November 1981 12:27-EST
From: Mark L. Miller <MILLER at MIT-AI>
Subject: WorkS Digest V1 #35
In response to DLW's remarks about things like the Apollo probably
losing out to slick end-user applications, I think perhaps a key point
has been overlooked. [I have seen major companies lose by providing
"non-programmable" (and thus hard to upgrade, inflexible, etc.)
systems geared to particular (usually incorrect) perceptions of
"slick" end-user applications.] Although it is probably accurate that
most end-users are not programmers and that it is the slick
applications (e.g.,VISICALC) that sell systems, it is also probably
accurate to assume that most slick applications (e.g., VISICALC) will
be written by software and OEM-systems companies, rather than hardware
manufacturers. The OEM's and software developers will choose things
like Apollos or LISP machines based on several factors: perceived
power and flexibility of the basic programming environment and
development tools, price relative to the market for the slick
application, etc. I believe that Apollos and LISPM's will flourish,
but that most sales will be via demand for particular packages (e.g.,
"What machine do I need if I want to run VISICALC" -> "What machine do
I need to run Daedalus?" etc.) Perhaps the best OA systems will be
written by separate software vendors serving as OEM's for systems such
as Apollo. Regards, Mark (Miller, DallaSoft)
------------------------------
Date: 15 Nov 1981 1417-EST
From: G.PALEVICH at MIT-EECS
Subject: Smalltalk 80 bible
So just where do I (a humble student) go to get a copy of the
Smalltalk 80 specifications book and the 380K byte system tape?
I read in Infoworld that the Apple IV is 68000 based. I seem
to remember rumours that they had at least the window portion of
Smalltalk 80 up.
The Infoworld article also talked about two other Apple
computers: a redesign of the Apple II for 64K chip, and some sort of
portable (ala Osborne I) 68000 based machine -- possibly code-named
the Mackentosh.
I believe that Tandy is working on a 68000 based machine, too.
In fact, I bet just about everyone is going 16bit because of the
greater speed/power/RAM.
------------------------------
Date: 15 November 1981 23:13-EST
From: Brian P. Lloyd <LLOYD at MIT-AI>
Subject: Apple and 'Lisa'
While visiting Apple several months ago, I caught a glimple of a box
that bore no resemblence to any current Apple product. I snooped
around a bit and read the memos that people had tacked on the walls of
their cubicals. Although I could be wrong, I got the strong
impression that I saw their 'top secret' product (this was the new
products development group).
The device I saw looked much like a VT-100 (same form factor) and had
a mouse. They were experimenting with color graphic printers, and I
overheard some discussion of the quality of the bitmapped display. I
was unable to find out what processor is being used, but I did learn
that it is a 16 bit chip. They were most interested in my experience
with the Convergent Technologies cluster communications and OS
architecture.
If I had to guess I would say that Apple is trying to build a cross
between the Xerox 'Star' and the Convergent Technologies system. They
could actually have something as far as the hardware is concerned, but
I wasn't too sure about their software crew.
Brian
------------------------------
End of WorkS Digest
*******************
-------
∂17-Nov-81 0031 AVB WorkS Digest V1 #37
∂17-Nov-81 0027 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #37
Date: 17 Nov 1981 0254-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
Subject: WorkS Digest V1 #37
To: Works: ;
WorkS Digest Tuesday, 17 Nov 1981 Volume 1 : Issue 37
Today's Topics: New Radio Shack Computer
Smalltalk Kernel In C
Major Corporations and Workstations
Book Reference
DECUS C Compiler
----------------------------------------------------------------------
Date: 16 November 1981 1045-EST
From: Hank Walker at CMU-10A
Subject: new Radio Shack computer
The current ELECTRONICS claims that the new Tandy computer will be 68000-
based, and be out in Feb or March 1982.
------------------------------
Date: 16 Nov 1981 10:06 PST
From: Deutsch at PARC-MAXC
Subject: Re: WorkS Digest V1 #35
Re the Smalltalk kernel in C: I would guess the current kernel is
about 70% relatively environment-independent and 30%
environment-dependent. However, there is another important point: the
Smalltalk system includes its own instruction set, and the 70%
includes the emulator for it. If you are going to run native machine
instructions rather than the Smalltalk bytecodes, you will have to
write your own compiler and decompiler, and do some careful thinking
about how to retain the current pleasant properties of reasonably
direct mapping between the source and object codes. For example, with
the Smalltalk instruction set, the debugger can highlight the exact
spot in a procedure being executed.
Smalltalk is set up so that you can take any procedure whatever and
recode it in an underlying instruction set without any change to its
callers or the system structure. For this kind of thing, having C
underneath would work just fine.
------------------------------
Date: 16 Nov 1981 14:09:45-EST
From: rmc at CCA-UNIX (Mark Chilenskas)
Subject: Major Corporations and Workstations
Last year Mike Hammer of MIT was consulting with the OA group
at EXXON. I believe he was involved in designing a database for
integrating office functions. A student of his, Tim Anderson, was
to be working on an editor/word processor function for the same
project, but last i heard Tim was choosing another thesis, so the
whole thing may have fallen through. Anywho, it is a possibility
that EXXON is actually trying to do something major here.
R Mark Chilenskas
Chilenskas@ISIE
------------------------------
Date: 16 Nov 1981 13:53:21-CST
From: jacobson at uwisc
Subject: Book Reference
Cc: jacobson@uwisc
I have a reference to a book entitled Interactive Programming
Environments, edited by E. Sandewall, H. Shrobe, and D. Barstow.
I picked it up from somewhere (perhaps fa.works) about two weeks
ago. I recorded that it was published by McGraw-Hill, but they
don't know anything about it. If you know who has or will
publish this book, please let me know.
-Fred Jacobson (jacobson@uwisc)
------------------------------
Date: 16 November 1981 2248-est
From: Brian N. Hess <Hess.Unicorn at MIT-Multics>
Subject: DECUS C compiler
Cc: Lauren at UCLA-Security
It's pretty worthless. That is to say, we don't like it because it
doesn't compile Mince (our ersatz EMACS) at all. For $695, who can
afford to NOT use the Whitesmith's C compiler? (Both DECUS and
Whitesmith's run under RT, RSX, and RSTS.)
Brian
------------------------------
End of WorkS Digest
*******************
-------
∂18-Nov-81 0108 AVB WorkS Digest V1 #38
∂17-Nov-81 2231 Jonathan Alan Solomon <JSol at RUTGERS> WorkS Digest V1 #38
Date: 17 Nov 1981 2342-EST
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WorkS at Rutgers
Subject: WorkS Digest V1 #38
To: Works: ;
WorkS Digest Wednesday, 18 Nov 1981 Volume 1 : Issue 38
Today's Topics: Exxon's Answer To The Star
Programming Environments - Operating System Vs. User Interface
----------------------------------------------------------------------
Date: 17 November 1981 17:25-EST
From: Steven T. Kirsch <SK at MIT-MC>
Subject: Exxon
Xonex [which is Exxon spelled sideways] is the Exxon company that is
building Exxon's answer to Star; it has a full bitmap and other nice
features that I am not allowed to disclose. However, the system is
very special case (i.e., like Wang) and concepts such as
"extensibility and customizability" seem to be foreign to the people
there. The software is impressive, but last I saw, they were still
coding in a macro assember.
------------------------------
Date: 17 November 1981 17:41-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject: WorkS Digest V1 #35: Programming environments
To: BillW at SRI-KL
A programming environment supports development of programs. Examples
are Harvard PDS, CMU Gandalf, PWB/Unix (shell and utilities).
An operating system supports running of programs and storage of data
(including, presumably, the programs which implement the programming
environment). Examples are Tops-20, Unix.
A programming system supports cooperation of running programs. In
most places, this consists of a set of conventions. In Unix, for
instance, it consists of conventions on the use of pipes and the
passage of textual parameters. Examples are the conventions of
Multics, Tops-10 (CCL files!).
A general user interface (there appears to be no standard name for
this and moreover it is often incorporated into the OS itself)
supports user control of the running of programs. Examples are
Tops-20 Exec, Unix Shell, DDT/Hactrn. Note that the Tops-10 "monitor"
is both an operating system and an interface.
The above classification is not to imply that the distinctions are
always sharp, nor that the best organization separates the levels.
Some very successful systems (Lisp Machine, for instance) blur many of
the lines; more and more other lines, such as those between
programming language, system, and environment, are similarly blurred.
There is a large literature on the first two topics. The third and
fourth topics are less discussed in themselves, although instances are
sometimes reported in the literature.
In all of these areas, there are debates about the right way to do
things. Some typical dimensions of dispute are the degree to which a
PE "understands" what it is working on (in PWB/Unix, not at all: it is
just a string of characters to most tools; while in Gandalf and PDS it
is structured and cannot be dealt with as a string of characters); the
degree of integration of parts of the system (again, in Unix almost
none--the toolbox approach; in PDS, very great); the amount of
structure in interfaces in PS's (in Unix, arguments are just strings
which may be interpreted as desired; in Multics, they are PL/I
objects); ... etc. etc. ad infinitum.
In any case, there is an extensive literature especially on
programming environments. See Horst Huenke's (some libraries may
transcribe u umlaut as 'u', giving Hunke) recent collection for a
starting point.
Stavros Macrakis
------------------------------
End of WorkS Digest
*******************
-------
∂18-Nov-81 2315 AVB WORKS Digest V1 #22
∂23-Oct-81 2321 Jonathan Alan Solomon <JSol at RUTGERS> WORKS Digest V1 #22
Date: 24 Oct 1981 0154-EDT
From: Jonathan Alan Solomon <JSol at RUTGERS>
Reply-to: WORKS at Rutgers
Subject: WORKS Digest V1 #22
To: Works: ;
WorkS Digest Friday, 24 Oct 1981 Volume 1 : Issue 22
Today's Topics: BBN BitGraph Terminal
The Alto Users Handbook - Cleared For Print By Xerox
----------------------------------------------------------------------
Date: 23 Oct 1981 (Friday) 1521-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Interesting 68K workstation (?)
cc: MORGAN (Howard Morgan)
Begin forwarded messages
Date: 22 October 1981 18:56-EDT
From: Bern Niamir <BERN at MIT-MC>
Subject: Favorite terminals
To: decvax!duke!unc!smb at UCB-C70
cc: INFO-TERMS at MIT-MC, BERN at MIT-MC
BBN has recently sold us a terminal called the BitGraph Terminal.
1024 * 768 bit mapped screen, 15" monochrome monitor, 40 Hz.
interlaced.
68000 micro (7 MHz.) with 128 Kbyte of RAM, 32 KByte of ROM, and 64
bytes of EAROM, 4 rs232 ports up to 19.2 Kbps, one 20 ma current loop
interface, and EIA rs-422 sync. HDLC serial link up to 200 Kbps.
All on one board. Expansion bus (Motorola Versabus) for additional
memory and IO. Maximum (in cabinet I believe) memory: 2048 Kbytes.
Speaker and programmable sound generator.
VT-100 keyboard.
Software in ROM: emulates VT52 and teleray (?), future software: HP
and TEKTRONIX 4010 graphics terminal emulation. For hackers: write
your own software. Code and fonts downloadable.
Price: $4500 single quant.
Bern
[End forwarded messages]
------------------------------
Date: 23 Oct 1981 1607-PDT
From: Richard Furuta <FURUTA at WASHINGTON>
Subject: The Alto User's Handbook
To: editor-people at SU-SCORE
cc: jeff at WASHINGTON, furuta at WASHINGTON
Some of you may be interested to know that that old underground
classic "The Alto User's Handbook" has been cleared for
release at Xerox and is available from Sara Dake at
Xerox-PARC. This handbook includes writeups on
Bravo, Markup and Draw.
------------------------------
End of WorkS Digest
*******************
-------